在 使用mysql时,有时需要查询出某个字段不重复的记录,虽然mysql提供有distinct这个关键字来过滤掉多余的重复记录只保留一条,但往往只用 它来返回不重复记录的条数,而不是用它来返回不重记录的所有值。其原因是distinct只能返回它的目标字段,而无法返回其它字段,这个问题让我困扰了 很久,用distinct不能解决的话,我只有用二重循环查询来解决,而这样对于一个数据量非常大的站来说,无疑是会直接影响到效率的。所以我花了很多时 间来研究这个问题,网上也查不到解决方案,期间把容容拉来帮忙,结果是我们两人都郁闷了。。。。。。。。。
下面先来看看例子:
table
id name
1 a
2 b
3 c
4 c
5 b
库结构大概这样,这只是一个简单的例子,实际情况会复杂得多。
比如我想用一条语句查询得到name不重复的所有数据,那就必须使用distinct去掉多余的重复记录。
select distinct name from table
得到的结果是:
name
a
b
c
好像达到效果了,可是,我想要得到的是id值呢?改一下查询语句吧:
select distinct name, id from table
结果会是:
id name
1 a
2 b
3 c
4 c
5 b
distinct怎么没起作用?作用是起了的,不过他同时作用了两个字段,也就是必须得id与name都相同的才会被排除。。。。。。。
我们再改改查询语句:
select id, distinct name from table
很遗憾,除了错误信息你什么也得不到,distinct必须放在开头。难到不能把distinct放到where条件里?能,照样报错。。。。。。。
很麻烦吧?确实,费尽心思都没能解决这个问题。没办法,继续找人问。
拉住公司里一JAVA程序员,他给我演示了oracle里使用distinct之后,也没找到mysql里的解决方案,最后下班之前他建议我试试group by。
试了半天,也不行,最后在mysql手册里找到一个用法,用group_concat(distinct name)配合group by name实现了我所需要的功能,兴奋,天佑我也,赶快试试。
报错。。。。。。。。。。。。郁闷。。。。。。。连mysql手册也跟我过不去,先给了我希望,然后又把我推向失望,好狠哪。。。。
再仔细一查,group_concat函数是4.1支持,晕,我4.0的。没办法,升级,升完级一试,成功。。。。。。
终于搞定了,不过这样一来,又必须要求客户也升级了。
突然灵机一闪,既然可以使用group_concat函数,那其它函数能行吗?
赶紧用count函数一试,成功,我。。。。。。。想哭啊,费了这么多工夫。。。。。。。。原来就这么简单。。。。。。
现在将完整语句放出:
select *, count(distinct name) from table group by name
结果:
id name count(distinct name)
1 a 1
2 b 1
3 c 1
最后一项是多余的,不用管就行了,目的达到。。。。。
唉,原来mysql这么笨,轻轻一下就把他骗过去了,郁闷也就我吧(对了,还有容容那家伙),现在拿出来希望大家不要被这问题折腾。
哦,对,再顺便说一句,group by 必须放在 order by 和 limit之前,不然会报错,差不多了,发给容容放网站上去,我继续忙碌。。。。。。
整理:sql server 中sql语句执行顺序
SQL Server 查询处理中的各个阶段(SQL执行顺序)
每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只是最后一步生成的表才会返回 给调用者。如果没有在查询中指定某一子句,将跳过相应的步骤。下面是对应用于SQL server 2000和SQL Server 2005的各个逻辑步骤的简单描述。
(1)FROM [left_table]
(3)<join_type> JOIN <right_table>
(2) ON <join_condition>
(4)WHERE <where_condition>
(5)GROUP BY <group_by_list>
(6)WITH <CUBE | RollUP>
(7)HAVING <having_condition>
(10)ORDER BY <order_by_list>
逻辑查询处理阶段简介
- FROM:对FROM子句中的前两个表执行笛卡尔积(Cartesian product)(交叉联接),生成虚拟表VT1
- ON:对VT1应用ON筛选器。只有那些使<join_condition>为真的行才被插入VT2。
- OUTER(JOIN):如 果指定了OUTER JOIN(相对于CROSS JOIN 或(INNER JOIN),保留表(preserved table:左外部联接把左表标记为保留表,右外部联接把右表标记为保留表,完全外部联接把两个表都标记为保留表)中未找到匹配的行将作为外部行添加到 VT2,生成VT3.如果FROM子句包含两个以上的表,则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3,直到处理完所有的表为止。
- WHERE:对VT3应用WHERE筛选器。只有使<where_condition>为true的行才被插入VT4.
- GROUP BY:按GROUP BY子句中的列列表对VT4中的行分组,生成VT5.
- CUBE|ROLLUP:把超组(Suppergroups)插入VT5,生成VT6.
- HAVING:对VT6应用HAVING筛选器。只有使<having_condition>为true的组才会被插入VT7.
- SELECT:处理SELECT列表,产生VT8.
- DISTINCT:将重复的行从VT8中移除,产生VT9.
- ORDER BY:将VT9中的行按ORDER BY 子句中的列列表排序,生成游标(VC10).
- TOP:从VC10的开始处选择指定数量或比例的行,生成表VT11,并返回调用者。
注:步骤10,按ORDER BY子句中的列列表排序上步返回的行,返回游标VC10.这一步是第一步也是唯一一步可以使用SELECT列表中的列别名的步骤。这一步不同于其它步骤的 是,它不返回有效的表,而是返回一个游标。SQL是基于集合理论的。集合不会预先对它的行排序,它只是成员的逻辑集合,成员的顺序无关紧要。对表进行排序 的查询可以返回一个对象,包含按特定物理顺序组织的行。ANSI把这种对象称为游标。理解这一步是正确理解SQL的基础。
因为这一步不返回表(而是返回游标),使用了ORDER BY子句的查询不能用作表表达式。表表达式包括:视图、内联表值函数、子查询、派生表和共用表达式。它的结果必须返回给期望得到物理记录的客户端应用程序。例如,下面的派生表查询无效,并产生一个错误:
select *
from(select orderid,customerid from orders order by orderid)
as d
下面的视图也会产生错误
create view my_view
as
select *
from orders
order by orderid
在SQL中,表表达式中不允许使用带有ORDER BY子句的查询,而在T—SQL中却有一个例外(应用TOP选项)。
所以要记住,不要为表中的行假设任何特定的顺序。换句话说,除非你确定要有序行,否则不要指定ORDER BY 子句。排序是需要成本的,SQL Server需要执行有序索引扫描或使用排序运行符。
推荐一段SQL代码:行列转置


































这样做确实是爽了自己, 可苦了机器, 服务器还需要在我们的杂乱无章的 SQL 语句中寻找它下一句需要执行的关键字在哪里.
效率嘛, 由于我们的感觉神经对秒以下的变化实在不敏感, 暂且就认为自已写的 SQL 顺序无关紧要, "反正没什么变化!", 呵呵.其实服务器对每句 SQL 解析时间都会有详细记录的, 大家可以看一下自已按习惯写的 SQL 和按标准顺序写的SQL解析时间差别有多大.
因此, 建议大家在平时工作中 SQL 语句按标准顺序写, 一是专业, 二是实用, 呵呵, 不过我觉得最主要的是心里感觉舒服.
标准的 SQL 的解析顺序为:
(1).FROM 子句, 组装来自不同数据源的数据
(2).WHERE 子句, 基于指定的条件对记录进行筛选
(3).GROUP BY 子句, 将数据划分为多个分组
(4).使用聚合函数进行计算
(5).使用 HAVING 子句筛选分组
(6).计算所有的表达式
(7).使用 ORDER BY 对结果集进行排序
举例说明: 在学生成绩表中 (暂记为 tb_Grade), 把 "考生姓名"内容不为空的记录按照 "考生姓名" 分组, 并且筛选分组结果, 选出 "总成绩" 大于 600 分的.
标准顺序的 SQL 语句为:
select 考生姓名, max(总成绩) as max总成绩
from tb_Grade
where 考生姓名 is not null
group by 考生姓名
having max(总成绩) > 600
order by max总成绩
在上面的示例中 SQL 语句的执行顺序如下:
(1). 首先执行 FROM 子句, 从 tb_Grade 表组装数据源的数据
(2). 执行 WHERE 子句, 筛选 tb_Grade 表中所有数据不为 NULL 的数据
(3). 执行 GROUP BY 子句, 把 tb_Grade 表按 "学生姓名" 列进行分组
(4). 计算 max() 聚集函数, 按 "总成绩" 求出总成绩中最大的一些数值
(5). 执行 HAVING 子句, 筛选课程的总成绩大于 600 分的.
(7). 执行 ORDER BY 子句, 把最后的结果按 "Max 成绩" 进行排序.
--1.from
--2.on
--3.outer(join)
--4.where
--5.group by
--6.cube|rollup
--7.having
--8.select
--9.distinct
--10.order by
--11.top
1. 逻辑查询处理步骤序号
(8)SELECT (9)DISTINCT (11)<TOP_specification> <select_list>
(1)FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4)WHERE <where_condition>
(5)GROUP BY <group_by_list>
(6)WITH {CUBE | ROLLUP}
(7)HAVING <having_condition>
(10)ORDER BY <order_by_list>
每个步骤产生一个虚拟表,该虚拟表被用作下一个步骤的输入。
只有最后一步生成的表返回给调用者。
如果没有某一子句,则跳过相应的步骤。
1. FROM:
对FROM子句中的前两个表执行笛卡尔积,生成虚拟表VT1。
2. ON:
对VT1应用ON筛选器。只有那些使<join_condition>为真的行才被插入VT2。
3. OUTER(JOIN):
如果指定了OUTER JOIN,保留表中未找到匹配的行将作为外部行添加到VT2,生成VT3。
如果FROM子句包含两个以上的表,则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3,直到处理完所有的表为止。
4. 对VT3应用WHERE筛选器。只有使<where_condition>为TRUE的行才被插入VT4。
5. GROUP BY:
按GROUP BY 子句中的列列表对VT4中的行分组,生成VT5。
6. CUBE|ROLLUP:
把超组插入VT5,生成VT6。
7. HAVING:
对VT6应用HAVING筛选器。
只有使<having_condition>为TRUE的组才会被插入VT7。
注:having不能单独使用,having子句是对分组后的记录的筛选,所以有having必须要有group by
8. SELECT:
处理SELECT列表,产生VT8。
9. DISTINCT:
将重复的行从VT8中移除,产生VT9。
10. ORDER BY:
将VT9中的行按ORDER BY子句中的列列表排序,生成一个有表(VC10)。
11. TOP:从VC10的开始处选择指定数量或比例的行,生成表VT11,并返回给调用者。
注:top n可以实现分页
select top 20 * from 雇员 ------第一页
select top 20 * from 雇员
where 身份证号码 not in (select top 20 身份证号码 from 雇员) ------第二页
2. 准备数据
SET NOCOUNT ON;
USE tempdb;
GO
IF OBJECT_ID('dbo.Orders') IS NOT NULL
DROP TABLE dbo.Orders;
GO
IF OBJECT_ID('dbo.Customers') IS NOT NULL
DROP TABLE dbo.Customers;
GO
CREATE TABLE dbo.Customers
(
customerid CHAR(5) NOT NULL PRIMARY KEY,
city VARCHAR(10) NOT NULL
);
INSERT INTO dbo.Customers(customerid,city) VALUES('FISSA', 'Madrid');
INSERT INTO dbo.Customers(customerid,city) VALUES('FRNDO', 'Madrid');
INSERT INTO dbo.Customers(customerid,city) VALUES('KRLOS', 'Madrid');
INSERT INTO dbo.Customers(customerid,city) VALUES('MRPHS', 'Zion');
CREATE TABLE dbo.Orders
(
orderid INT NOT NULL PRIMARY KEY,
customerid CHAR(5) NULL REFERENCES Customers(customerid)
);
INSERT INTO dbo.Orders(orderid, customerid) VALUES(1,'FRNDO');
INSERT INTO dbo.Orders(orderid, customerid) VALUES(2,'FRNDO');
INSERT INTO dbo.Orders(orderid, customerid) VALUES(3,'KRLOS');
INSERT INTO dbo.Orders(orderid, customerid) VALUES(4,'KRLOS');
INSERT INTO dbo.Orders(orderid, customerid) VALUES(5,'KRLOS');
INSERT INTO dbo.Orders(orderid, customerid) VALUES(6,'MRPHS');
INSERT INTO dbo.Orders(orderid, customerid) VALUES(7, NULL);
执行结果:
3. 查询语句
USE tempdb;
GO
SELECT C.customerid, COUNT(O.orderid) AS numorders
FROM dbo.Customers AS C
LEFT OUTER JOIN dbo.Orders AS O
ON C.customerid = O.customerid
WHERE C.city = 'Madrid'
GROUP BY C.customerid
HAVING COUNT(O.orderid) < 3
ORDER BY numorders;
执行结果:
4. 逻辑查询处理步骤详解
1. 执行笛卡尔乘积,形成VT1。如果左表包含n行,右表包含m行,VT1将包含n×m行。
执行结果VT1:
2. 应用ON 筛选器,只有<join_condition>为TRUE的那些行才会包含在VT2中。
ON C.customerid = O.customerid
三值逻辑:
TRUE、FALSE、UNKNOWN为SQL中逻辑表达式的可能值。
UNKNOWN值通常出现在含NULL值的逻辑表达式中,如NULL > 42; NULL = NULL; X + NULL > Y。
NOT TRUE 等于 FALSE
NOT FALSE 等于TRUE
NOT UNKNOWN 等于 UNKNOWN
所有的查询筛选器,如ON、WHERE、HAVING把UNKNOWN看作为FALSE处理。
CHECK约束中的UNKNOWN值被当作TRUE对待。如果表中含有一个CHECK约束,要求salary列的值必须大于0,则插入salary为NULL的行时可以被接受。
UNIQUE约束、排序操作、分组操作认为两个NULL值是相等的。如,表中有一列定义了UNIQUE约束,则无法向表中插入该列值为NULL的两行。GROUP BY子句把所有NULL值分在一组。ORDERB BY子句把所有NULL值排列在一起。
对VT1增加ON筛选器的结果VT2:
3. 添加外部行,通过指定LEFT、RIGHT、FULL中的一种OUTER JOIN,可以把左表、右表、所有表标记为保留表。把一个表设为保留表表示返回该表的所有行,即使<join_condition>已经执行过筛选。保留表中的这些行被称为外部行,外部行中非保留表的属性被赋予NULL,最后生成VT3:
4. 应用WHERE筛选器,只有符合<where_condition>的行才会成为VT4的一部分。因为数据还没有被分组,所以不能使用聚合筛选器,例如WHERE orderdate = MAX(orderdate)。也不能饮用SELECT列表中的别名,因为SELECT列表这时还没有被处理,例如SELECT YEAR(orderdate) AS orderyear WHERE orderyear > 2000。
对于包含OUTER JOIN子句的查询,如何判断到底是在ON筛选器还是在WHERE筛选器中指定逻辑表达式:ON在添加外部行前被应用,WHERE在外部行添加之后被应用。ON筛选器对保留表中部分行的一处不是最终的,因为还要执行添加外部行的步骤,而WHERE筛选器对这些行的移除是最终的。
只有在使用外部联接时,ON和WHERE子句才会存在这种逻辑限制,当使用内部联接时,在那里指定逻辑表达式都无所谓,因为没有上面的步骤3。
WHERE C.city = 'Madrid'
生成虚拟表VT4:
5. 分组。GROUP BY子句中列列表的每个唯一的值组合成为一组,生成VT5:
Groups
|
Raw
|
C.customerid
|
|
FISSA
|
|
FRNDO
|
|
KRLOS
|
VT5由两部分组成:Group Section和Raw Section。
如果在查询中指定了GROUP BY子句,则后面的所有步骤(如:HAVING、SELECT)只能指定可以为成组得到的标量值的表达式。也就是说,表达式的结果是GROUP BY列表中的列/表达式(如:C.customer)或聚合函数(如:COUNT(O.orderid))。该限制是因为最终的结果集中最多只为每一个组包含一行。
这一阶段认为两个NULL是相等的。所有的NULL值会被分配到一组。
如果指定GROUP BY ALL,则在WHERE筛选中被移除的组将被添加到VT5中,且原始部分为空集合。在后面的步骤中,对该组应用COUNT聚合函数的结果将为0,应用其他聚合函数的结果为NULL。最好不要使用GROUP BY ALL。
6. 使用CUBE或ROLLUP选项,将创建超组并把它添加到上一步返回的虚拟表中,生成VT6。
7. 应用HAVING 筛选器 ,只有符合<having_condition>的组才会成为VT7的一部分。HAVING是唯一的应用到已分组数据的筛选器。
HAVING COUNT(O.orderid) < 3
在这里使用了COUNT(O.orderid),而不是COUNT(*),所以外部行因为O.orderid为NULL,于是不计入COUNT中。如FISSA这组的COUNT(O.orderid)为0.
红色部分为被HAVING筛选掉的分组。
Groups
|
Raw
|
C.customerid
|
|
FISSA
|
|
FRNDO
|
|
KRLOS
|
8. 处理SELECT列表,为不是基列的表达式应用别名,使其在结果表中有一个名称。在SELECT列表中创建的别名不能再前面的步骤中使用,甚至不能再SELECT列表中使用,只能在ORDER BY中使用。
SELECT C.customerid, COUNT(O.orderid) AS numorders
生成VT8:
逻辑上,应当假设所有操作同时发生。
9. 应用DISTINCT子句,如果查询中指定了DISTINCT子句,将从上一步返回的虚拟表中移除重复行,并生成虚拟表VT9。使用GROUP BY,再使用DISTINCT是多余的。
10. 应用ORDER BY子句,按照ORDER BY子句中的列列表排序上一步返回的行,返回游标VC10。只有这一步可以使用SELECT别名。如果指定了DISTINCT,ORDER BY子句中的表达式只能访问上一步返回的虚拟表,只能按已经SELECT的列排序。
ANSI SQL 1999中增强了ORDER BY的支持,允许访问SELECT阶段的输入虚拟表和输出虚拟表。就是说如果未指定DISTINCT,可以在ORDER BY子句中指定任何可以在SELECT子句中使用的表达式,可以按最后结果集中不存在的表达式排序。
ORDER BY numorders;
也可以在ORDER BY子句中指定SELECT列表中结果列的序号:
ORDER BY 2, 1;
但是尽量不要这样去做,因为可能改变了SELECT列表却忘记了修改ORDER BY列表,而且当SELECT列表很长时,查序号不是一个好方法。
因为这一步不是返回表,而是返回游标,使用了ORDER BY子句的查询不能用作表表达式。表表达式包括:视图、内联表值函数、子查询、派生表和共用表表达式(CTE)。
不要为表中的行假定顺序,除非确实需要有序行,否则不要指定ORDER BY子句。排序是需要成本的,SQL Server需要执行有序索引扫描或使用排序运算符。
ORDER BY这一步认为两个NULL是相等的,所有的NULL会被排列在一起,ANSI并没有规定NULL比已知值高还是低,而是把这个问题留给了具体实现,在T-SQL中NULL排位比已知值低。
ORDER BY numorders
返回的游标VC10:
11. 应用TOP选项,从游标的最前面选择指定的行数,生成表VT11并返回给调用者。在SQLServer 2000中,TOP的输入必须为常量,而在2005中可以是任何独立的表达式。
如果没有ORDER BY子句或WITH TIES选项,返回的行正好是物理上最先访问的行,可能会产生不同的结果。
只有指定了TOP选项,才可以在表表达式中使用带有ORDER BY子句的查询:
SELECT *
FROM (SELECT TOP 100 PERCENT orderid, customerid
FROM dbo.Orders
ORDER BY orderid) AS D;
相关推荐
内容概要:本文详细介绍了基于SpringBoot和Vue开发的养老院管理系统的具体实现细节。该系统采用前后端不分离的架构,旨在快速迭代并满足中小项目的开发需求。文中涵盖了多个关键技术点,如数据库设计(组合唯一约束、触发器)、定时任务(@Scheduled、@Async)、前端数据绑定(Vue的条件渲染和动态class绑定)、权限控制(RBAC模型、自定义注解)以及报表导出(SXSSFWorkbook流式导出)。此外,还讨论了开发过程中遇到的一些常见问题及其解决方案,如CSRF防护、静态资源配置、表单提交冲突等。 适合人群:具备一定Java和前端开发经验的研发人员,尤其是对SpringBoot和Vue有一定了解的开发者。 使用场景及目标:适用于需要快速开发中小型管理系统的团队,帮助他们理解如何利用SpringBoot和Vue进行全栈开发,掌握前后端不分离架构的优势和注意事项。 其他说明:文章不仅提供了详细的代码示例和技术要点,还分享了许多实用的小技巧和避坑指南,有助于提高开发效率和系统稳定性。
家族企业如何应对人才流失问题?
员工关怀制度.doc
内容概要:本文详细探讨了对传统蚁群算法进行改进的方法,特别是在路径规划领域的应用。主要改进措施包括:采用排序搜索机制,即在每轮迭代后对所有路径按长度排序并只强化前20%的优质路径;调整信息素更新规则,如引入动态蒸发系数和分级强化策略;优化路径选择策略,增加排序权重因子;以及实现动态地图调整,使算法能够快速适应环境变化。实验结果显示,改进后的算法在收敛速度上有显著提升,在复杂地形中的表现更加稳健。 适合人群:从事路径规划研究的技术人员、算法工程师、科研工作者。 使用场景及目标:适用于需要高效路径规划的应用场景,如物流配送、机器人导航、自动驾驶等领域。目标是提高路径规划的效率和准确性,减少不必要的迂回路径,确保在动态环境中快速响应变化。 其他说明:改进后的蚁群算法不仅提高了收敛速度,还增强了对复杂环境的适应能力。建议在实际应用中结合可视化工具进行调参,以便更好地观察和优化蚂蚁的探索轨迹。此外,还需注意避免过度依赖排序机制而导致的过拟合问题。
内容概要:本文详细介绍了利用粒子群优化(PSO)算法解决配电网中分布式光伏系统的选址与定容问题的方法。首先阐述了问题背景,即在复杂的配电网环境中选择合适的光伏安装位置和确定合理的装机容量,以降低网损、减小电压偏差并提高光伏消纳效率。接着展示了具体的PSO算法实现流程,包括粒子初始化、适应度函数构建、粒子位置更新规则以及越界处理机制等关键技术细节。文中还讨论了目标函数的设计思路,将多个相互制约的目标如网损、电压偏差和光伏消纳通过加权方式整合为单一评价标准。此外,作者分享了一些实践经验,例如采用前推回代法进行快速潮流计算,针对特定应用场景调整权重系数,以及引入随机波动模型模拟光伏出力特性。最终实验结果显示,经过优化后的方案能够显著提升系统的整体性能。 适用人群:从事电力系统规划与设计的专业人士,尤其是那些需要处理分布式能源集成问题的研究人员和技术人员。 使用场景及目标:适用于希望深入了解如何运用智能优化算法解决实际工程难题的人士;旨在帮助读者掌握PSO算法的具体应用方法,从而更好地应对配电网中分布式光伏系统的选址定容挑战。 其他说明:文中提供了完整的Matlab源代码片段,便于读者理解和复现研究结果;同时也提到了一些潜在改进方向,鼓励进一步探索和创新。
内容概要:本文详细介绍了丰田Prius2004永磁同步电机的设计流程,涵盖从初始参数计算到最终温升仿真的各个环节。首先利用Excel进行基本参数计算,如铁芯叠厚、定子外径等,确保设计符合预期性能。接着使用Maxwell进行参数化仿真,通过Python脚本自动化调整磁钢尺寸和其他关键参数,优化电机性能并减少齿槽转矩。随后借助橡树岭实验室提供的实测数据验证仿真结果,确保模型准确性。最后采用MotorCAD进行温升仿真,优化冷却系统设计,确保电机运行安全可靠。文中还分享了许多实用技巧,如如何正确设置材料参数、避免常见的仿真错误等。 适合人群:从事电机设计的专业工程师和技术人员,尤其是对永磁同步电机设计感兴趣的读者。 使用场景及目标:适用于希望深入了解永磁同步电机设计全过程的技术人员,帮助他们在实际工作中提高设计效率和精度,解决常见问题,优化设计方案。 其他说明:文章提供了丰富的实战经验和具体的操作步骤,强调了理论与实践相结合的重要性。同时提醒读者注意一些容易忽视的细节,如材料参数的选择和仿真模型的准确性。
内容概要:本文详细介绍了基于DSP28335的单相逆变器的设计与实现,涵盖了多个关键技术模块。首先,ADC采样模块用于获取输入电压和电流的数据,确保后续控制的准确性。接着,PWM控制模块负责生成精确的脉宽调制信号,控制逆变器的工作状态。液晶显示模块则用于实时展示电压、电流等重要参数。单相锁相环电路实现了电网电压的频率和相位同步,确保逆变器输出的稳定性。最后,电路保护程序提供了过流保护等功能,保障系统的安全性。每个模块都有详细的代码示例和技术要点解析。 适合人群:具备一定嵌入式系统和电力电子基础知识的研发人员,尤其是对DSP28335感兴趣的工程师。 使用场景及目标:适用于单相逆变器项目的开发,帮助开发者理解和掌握各个模块的具体实现方法,提高系统的可靠性和性能。 其他说明:文中不仅提供了具体的代码实现,还分享了许多调试经验和常见问题的解决方案,有助于读者更好地理解和应用相关技术。
SecureCRT安装包
内容概要:本文详细介绍了如何利用C#、WPF和MVVM模式构建一个大屏看板3D可视化系统。主要内容涵盖WPF编程设计、自定义工业控件、数据库设计、MVVM架构应用以及典型的三层架构设计。文中不仅提供了具体的代码实例,还讨论了数据库连接配置、3D模型绑定、依赖属性注册等关键技术细节。此外,文章强调了项目开发过程中需要注意的问题,如3D坐标系换算、MVVM中命令传递、数据库连接字符串加密等。 适合人群:具备一定C#编程基础,对WPF和MVVM模式有一定了解的研发人员。 使用场景及目标:适用于希望深入了解WPF和MVVM模式在实际项目中应用的开发者,特别是那些从事工业控制系统、数据可视化平台开发的专业人士。通过学习本文,读者可以掌握如何构建高效、稳定的大屏看板3D可视化系统。 其他说明:本文提供的设计方案和技术实现方式,可以帮助开发者更好地理解和应用WPF和MVVM模式,同时也能为相关领域的项目开发提供有价值的参考。
基于ssm的系统设计,包含sql文件(Spring+SpringMVC+MyBatis)
内容概要:本文详细介绍了利用COMSOL进行非厄米超表面双参数传感器的设计与实现。首先,通过构建超表面单元并引入虚部折射率,实现了PT对称系统的增益-损耗交替分布。接着,通过频域扫描和参数化扫描,捕捉到了复频率空间中的能级劈裂现象,并找到了奇异点(Exceptional Point),从而显著提高了传感器对微小扰动的敏感度。此外,文章探讨了双参数检测的独特优势,如解耦温度和折射率变化的能力,并展示了其在病毒检测、工业流程监控等领域的潜在应用。 适合人群:从事光学传感器研究的专业人士,尤其是对非厄米系统和COMSOL仿真感兴趣的科研人员。 使用场景及目标:适用于需要高精度、多参数检测的应用场合,如生物医学检测、环境监测等。目标是提高传感器的灵敏度和分辨率,解决传统传感器中存在的参数交叉敏感问题。 其他说明:文中提供了详细的建模步骤和代码片段,帮助读者理解和重现实验结果。同时,强调了在建模过程中需要注意的关键技术和常见问题,如网格划分、参数设置等。
怎样健全员工福利体系.docx
离职证明范本.doc
6538b79724855900a9c930904a302920.part6
员工离职单.doc
内容概要:本文详细介绍了在COMSOL中进行超材料异常折射仿真的关键技术。首先解释了异常折射现象及其产生的原因,接着通过具体代码展示了如何利用相位梯度和结构色散精确计算折射角。文中还讨论了边界条件的设置、网格划分的优化以及参数化扫描的应用。此外,提供了多个实用脚本和技巧,帮助提高仿真的精度和效率。最后强调了验证结果的重要性和一些常见的注意事项。 适合人群:从事电磁仿真研究的专业人士,尤其是对超材料和异常折射感兴趣的科研人员和技术开发者。 使用场景及目标:适用于需要深入理解和解决超材料中异常折射问题的研究项目。主要目标是掌握COMSOL中异常折射仿真的完整流程,确保仿真结果的准确性并优化计算性能。 其他说明:文章不仅提供了详细的代码示例和技术细节,还分享了许多实践经验,有助于读者更好地应对实际仿真过程中可能出现的问题。
招聘工作数据分析表.xls
platform-tools-latest-windows.zip
个人资料临时存储QT资源
内容概要:本文详细介绍了微电网中三相交流下垂控制的工作原理和技术细节。首先,通过Matlab/Simulink搭建模型,展示了传统阻感型线路下垂特性的实现方法,特别是有功-频率和无功-电压下垂曲线的解析。文中强调了关键参数Kp和Kq的选择及其对系统稳定性的影响,并通过具体的仿真案例展示了不同参数设置下的动态响应。此外,文章讨论了波形分析中的注意事项,如谐波成分、滤波器设计以及虚拟阻抗的应用。最后,通过Python和C语言实现了下垂控制器的代码示例,进一步解释了实际工程中的实现细节。 适合人群:从事微电网研究和开发的技术人员,尤其是对下垂控制感兴趣的电气工程师和研究人员。 使用场景及目标:适用于希望深入了解微电网下垂控制原理及其实际应用的研究人员和技术人员。目标是帮助读者掌握下垂控制的核心概念和技术实现,提高在实际工程项目中的调试和优化能力。 其他说明:文章不仅提供了理论分析,还包括了大量的仿真代码和波形图,使读者能够更好地理解和验证所学内容。同时,文中提到的实际调试经验和常见错误也为初学者提供了宝贵的指导。