MySQL DQL查询实战：SELECT执行顺序、分组聚合与多表连接全解析-北京尧图网络

数据查询语言Data Query LanguageDQL是MySQL课程里最值得花时间啃的一块也是我从带新人过程中感触最深的部分。DQL语句的核心就是SELECT工作中无论是业务取数、报表统计、数据核对还是排查线上问题95%的场景都是在和SELECT打交道。很多人把DQL理解成背几条查询语法其实完全不是一回事真正决定查询结果对不对、跑得快不快的是你对执行顺序、过滤时机、连接方式和分组统计口径的理解。这篇内容是MySQL基础系列的第二讲我把课堂上的讲解顺序和学员经常踩的坑放在一起适合刚学完建表、插入、修改和删除正准备进入查询阶段的人。耐心看完配合练习比零散翻文档要高效得多。1. 为什么DQL是MySQL课程里的分水岭1.1 DQL在SQL语言族中的位置初学MySQL时最先接触到的是四大类SQL数据定义语言DDL、数据操作语言DML、数据查询语言DQL、数据控制语言DCL。其中DDL管建库建表DML管插入、修改、删除DQL管查询DCL管权限。表面上看DQL只是读数据但实际工作中它是被调用最频繁的一类语句。一个很直观的例子业务系统每天产生的订单、用户行为、设备状态数据最终都要通过查询变成报表和分析结论。写接口时需要查询做数据分析时需要查询定位脏数据时需要查询。DML操作前通常还要先查询确认影响范围避免误删。所以很多面试题、实训环节都会把DQL作为重点考察对象因为它最能反映你对数据结构的理解程度。还有一个容易被忽略的点DQL并不只是简单的把数据列出来。它背后包含过滤、分组、聚合、排序、分页、连接、子查询这些能力。这些东西组合起来几乎可以完成你面对的所有取数需求。学透了DQL再去看视图、临时表、存储过程会发现那些都只是查询能力的延伸。1.2 学DQL到底在学什么我带实训班时候会把DQL学习拆成三个层次第一个层次是语法层也就是写得出能跑的SQL。比如知道SELECT后面可以跟列名、函数、表达式知道WHERE后面写条件知道GROUP BY怎么分组。这个层次只要多写就能过。第二个层次是逻辑层也就是知道SQL怎么执行。很多人卡在这一层症状是结果和预期不一致。比如为什么WHERE里不能直接用聚合函数为什么HAVING能做而WHERE不能做为什么ORDER BY写在最后却会影响分页结果。这些都需要理解执行顺序。第三个层次是性能层。同样的查询写法不同执行效率可能差几十倍。比如大表深分页为什么越翻越慢连接查询为什么建了索引才快子查询为什么会被改写。这些内容基础课只会浅尝辄止但作为新人你至少应该知道什么写法是危险的。这篇博文会按照语法——逻辑——性能的思路往下走尽量把每个关键点都讲透。2. SELECT骨架与执行顺序的底层逻辑2.1 SELECT语法骨架先看哪几块任何一条查询语句都可以套进这个骨架里SELECT [DISTINCT] 列名/表达式/聚合函数 FROM 表名 [WHERE 行级过滤条件] [GROUP BY 分组字段] [HAVING 分组后的过滤条件] [ORDER BY 排序字段] [LIMIT 偏移量, 条数]方括号里的都是可选项唯一必须写的是SELECT和FROM。初学者最喜欢犯的错误是上来就写一堆条件结果字段、表、条件之间的关系是乱的。我的建议是永远从最简形式开始先写SELECT * FROM 表名确认数据存在再一步步叠加过滤、分组、排序每加一层就运行一次观察结果变化。这里要说一个写SQL的基本态度能简单就不要复杂。一条能跑且语义清楚的查询远比一条炫技但没人看得懂的查询有价值。2.2 书写顺序不等于执行顺序这一点如果不理解后面学WHERE、GROUP BY、HAVING都会踩坑。SQL语句的书写顺序和数据库引擎的实际执行顺序是不一样的。实际的逻辑执行顺序大致是顺序步骤说明1FROM确定数据来源加载表2WHERE对表中的每一行进行过滤3GROUP BY按字段分组4HAVING对分组后的结果过滤5SELECT计算要输出的列和表达式6DISTINCT对结果去重7ORDER BY对结果排序8LIMIT截取指定行数为什么这个顺序如此重要因为它直接解释了很多怪现象。举个例子WHERE发生在GROUP BY之前所以WHERE里不能引用聚合函数的结果。你不可能在分组前就判断COUNT(*) 5因为这个时候还没有分组完成。同样的道理SELECT里定义的列别名在WHERE阶段还没有生成所以WHERE里不能用别名过滤但ORDER BY阶段可以因为执行到ORDER BY时SELECT已经算完了。我用一个生活化的类比来解释执行顺序就像做饭的过程。先买菜FROM再按新鲜程度挑拣食材WHERE然后把挑好的菜按种类分装GROUP BY分装后再决定哪些种类的菜上桌HAVING接着切菜摆盘SELECT最后按颜色顺序排列上桌ORDER BY只端出前几盘LIMIT。如果你在挑拣食材阶段就想知道某类菜一共有几盘那是做不到的因为还没到分装那一步。记住这张表后面所有疑难问题都能往这个框架里套。2.3 基础查询实操去重、别名、表达式先看一段最基础也是最常用的写法SELECT stu_id, name, age 1 AS age_next_year FROM student;这里age 1是对原始值的表达式运算AS age_next_year是给计算列起别名。别名可以省略AS直接写空格例如age 1 age_next_year但我建议显式写AS语义更清楚团队协作也不会产生歧义。去重用DISTINCT例如查看一共有哪些班级编号SELECT DISTINCT class_id FROM student;注意DISTINCT作用于后面所有列的组合而不是单单第一列。比如SELECT DISTINCT class_id, gender的意思是班级和性别的组合不重复不是只看班级不重复。新手经常在这里踩坑把组合去重误当成单列去重。另外查询常量列也是一种常见用法。比如在报表里加一列固定的标签SELECT 2024年统计 AS year_label, class_id FROM student;常量列不依赖表字段经常用来给后续程序处理做标记。基础但不冷门。3. WHERE过滤与运算符常见陷阱逐一套牢3.1 WHERE与HAVING的分工边界WHERE是行级过滤发生在分组之前HAVING是分组级过滤发生在分组之后。这个边界必须刻在脑子里。下面这个查询是按班级统计人数但只想看人数大于30人的班级。正确的写法是SELECT class_id, COUNT(*) AS cnt FROM student GROUP BY class_id HAVING cnt 30;如果把HAVING换成WHERESELECT class_id, COUNT(*) AS cnt FROM student WHERE COUNT(*) 30 GROUP BY class_id;这条语句会直接报错因为WHERE执行时GROUP BY还没有执行COUNT(*)在WHERE阶段是不允许使用的。记住WHERE处理的是行的条件HAVING处理的是组的条件。一个常见的扩展误区是有些人为了让查询快一点恨不得把所有条件都塞进WHERE。这不完全对。WHERE能做的事确实应该在WHERE做因为它能提前减少数据量但如果条件是针对聚合结果的就必须放在HAVING放WHERE里要么报错要么语义错误。为了效率可以在WHERE里先过滤部分行再做分组统计SELECT class_id, COUNT(*) AS cnt FROM student WHERE status 1 GROUP BY class_id HAVING cnt 30;这里status 1先排除掉无效学生再分组统计性能自然更好。写复杂查询之前先画一下哪些条件属于哪一步很有帮助。3.2 运算符使用中的经典坑WHERE后面几乎天天在跟运算符打交道但有四个坑让我印象特别深。第一个坑是NULL的判断。很多新人写出这样的语句SELECT * FROM student WHERE phone NULL;这条语句查不出任何结果因为 NULL不是一个合法条件。NULL表示未知值判断未知值只能用IS NULL或IS NOT NULL。正确的写法是SELECT * FROM student WHERE phone IS NULL;为什么会这样因为NULL不是值它无法参与等值比较。把NULL理解成这里的数据暂时缺失就很好想通了你不知道缺失内容和某个具体值是否相等所以 NULL永远返回未知。第二个坑是空字符串和NULL的区别。空字符串是一个长度为0的值NULL是缺失。统计电话为空的人时如果既包含NULL又包含空字符串需要写SELECT * FROM student WHERE phone IS NULL OR phone ;不能只写其中一个否则数据会漏。第三个坑是字符串和数字的隐式转换。假设手机号以varchar类型存储你写了WHERE phone 13812345678MySQL会对字符串列做隐式转换如果手机号里有少量非数字字符可能匹配不到甚至会导致索引失效。稳妥的做法是等号右边也加引号WHERE phone 13812345678;第四个坑是日期字符串和日期边界。字段类型是datetime时判断某一天的数据如果写WHERE order_date BETWEEN 2024-01-01 AND 2024-01-31那实际会查到2024-01-31 00:00:00及之前的数据2024-01-31当天零点之后的数据全部丢失。原因在于BETWEEN是闭区间会把上下界当成一个完整的比较。更稳妥的写法是WHERE order_date 2024-01-01 AND order_date 2024-02-01;前半条包含1月1日零点后半条排除2月1日零点正好覆盖整个1月。这条经验我在统计订单、日志场景里反复用到可以说是日期查询里最重要的习惯之一。3.3 实测中的排查条件写对但数据对不上有一次实训课上有个同学统计部门人数得到的人数比预期少很多。他的SQL简化版是这样的SELECT department_id, COUNT(*) FROM employee WHERE salary 5000 GROUP BY department_id;从语法结构上挑不出毛病但数据就是不对。后来检查发现employee表里面工资字段设计成了varchar里面混入了几个带单位的字符串导致和数字常量5000比较时那些行被过滤掉了。这类问题用肉眼很难发现排查方式是把过滤条件逐步放宽SELECT COUNT(*) FROM employee; -- 总数 SELECT COUNT(*) FROM employee WHERE salary IS NOT NULL; -- 非空 SELECT COUNT(*) FROM employee WHERE salary 5000; -- 过滤后三段对比很快就能定位是条件本身、数据类型还是空值的问题。这也是我想强调的调试习惯不要只盯着一句SQL看要分段验证行数变化。4. 聚合函数与GROUP BY分组统计实战4.1 COUNT、SUM、AVG、MAX、MIN的计算口径聚合函数把多行数据合成一个结果最常见的就是这些SELECT COUNT(*) AS total_cnt, COUNT(score) AS score_cnt, SUM(score) AS total_score, AVG(score) AS avg_score, MAX(score) AS max_score, MIN(score) AS min_score FROM exam_result;这五个函数里最容易出错的是COUNT。COUNT(*)会统计所有行数包括某个字段为NULL的行而COUNT(score)只统计score字段非NULL的行数。如果字段里NULL值很多两个数字会差得很明显这在做数据质量检查时是一个重要线索。SUM和AVG同样会忽略NULL值。比如某门课三个人参加成绩分别是80、90和NULLAVG(score)计算结果是85而不是56.7因为NULL那一行被直接忽略了。如果你希望把缺考的人按0分计入平均分就需要写AVG(IFNULL(score, 0))IFNULL把NULL替换成0语义完全不同。另一个细节是SUM对一个空结果集返回NULL而不是0所以判断销售总额是否是0和是否没有销售记录要用不同SQL。4.2 GROUP BY的分组逻辑再拆一下GROUP BY的作用可以理解为把多行数据按照一个或几个字段的取值归并成若干组组内行数可能很多但最终每个组只产出一行汇总结果。一个典型的误区是既然分组成一个组为什么SELECT里面可以混着写非分组字段比如SELECT class_id, gender, COUNT(*) FROM student GROUP BY class_id;这条语句在MySQL的默认模式下不会报错但gender的返回结果是随机的因为它不属于分组字段。这在业务上是一个隐患。标准SQL的思路是SELECT后面只能出现分组字段和聚合函数其他字段都不应该出现。MySQL 8.0默认开启了ONLY_FULL_GROUP_BY模式后这种写法会直接报错这是很好的保护。按多个字段分组也很常见例如按班级再按性别统计SELECT class_id, gender, COUNT(*) AS cnt FROM student GROUP BY class_id, gender;执行逻辑是先按class_id分一层再在class_id内部按gender分一层最终每个班级下男生女生各一行。多列分组的顺序会影响结果排序但不影响分组的整体结构。4.3 分组后过滤HAVING的正确打开方式HAVING在GROUP BY之后执行所以它可以使用聚合函数和别名。以统计各科平均分大于75分为例SELECT subject, AVG(score) AS avg_score FROM exam_result GROUP BY subject HAVING AVG(score) 75;这里的AVG(score) 75不能移入WHERE因为平均值是分组之后才能算出来的。HAVING还可以搭配多个条件HAVING AVG(score) 75 AND COUNT(*) 10表示平均分超过75且参加人数不少于10人的科目。这个场景在筛选有效统计样本时非常实用。提醒一个细节MySQL允许在HAVING里直接使用SELECT列别名例如HAVING avg_score 75但SQL标准并不推荐因为逻辑顺序上HAVING先于SELECT依赖别名会让人混淆执行顺序。我自己的习惯是写完整表达式或者聚合函数少用别名。5. ORDER BY排序与LIMIT分页的配合细节5.1 排序规则与多列排序ORDER BY负责结果排序默认是升序ASC降序用DESC。一个很容易忽略的点是排序是在SELECT之后执行的所以ORDER BY可以使用SELECT中的别名比如SELECT subject, AVG(score) AS avg_score FROM exam_result GROUP BY subject ORDER BY avg_score DESC;多列排序的写法是SELECT emp_id, department_id, salary FROM employee ORDER BY department_id ASC, salary DESC;执行逻辑很直接先按第一列排序第一列值相同的记录再按第二列排序。这个顺序写反了效果完全不同很多人以为多列排序是同时按两个字段排序其实不是它是嵌套的排序规则。NULL的排序位置也需要注意。MySQL默认升序时NULL排在最前面降序时NULL排在最后面。如果你希望把NULL排到最后可以写成ORDER BY ISNULL(phone), phone这里的ISNULL(phone)对NULL返回1对非NULL返回0升序时0排在1前面实际效果就是NULL记录被放到后面。5.2 LIMIT分页公式与深分页问题分页是后端开发里绕不开的需求语法是SELECT * FROM employee ORDER BY emp_id LIMIT 20, 10;这里表示跳过前20条返回从第21条开始的10条。如果参数是页码page和每页条数pageSize通用公式是LIMIT (page - 1) * pageSize, pageSize第一页就是LIMIT 0, 10第二页LIMIT 10, 10。这里最容易犯的错误是把两个参数顺序写反。LIMIT的第一个参数是偏移量第二个是条数很多人想当然地先写条数后写偏移量结果返回了错误的数据。关于分页有一个性能问题必须知道深分页越翻越慢。比如LIMIT 100000, 10要扫描并丢弃前100000条性能就会很差。常用优化方式是记住上一页的最后一条主键然后取主键大于它的固定条数SELECT * FROM employee WHERE emp_id 100234 ORDER BY emp_id LIMIT 10;这种基于游标的分页方式不依赖偏移量在数据量大的场景下效果很明显。如果是带复杂过滤条件的查询先把过滤结果缩小范围再分页也会有帮助。6. 多表连接INNER JOIN之外的选择6.1 连接的本质是笛卡尔积加条件过滤多表连接是DQL里让新手最头疼的部分但其实一句话就能说破连接就是把两张表的数据做笛卡尔积然后通过ON条件过滤掉不匹配的行。假设学生表有10行成绩表有20行没有任何条件的连接SELECT * FROM student JOIN score;会得到10乘20等于200行这种结果通常没有业务意义。如果加上连接条件SELECT * FROM student JOIN score ON student.stu_id score.stu_id;就只保留stu_id相等的记录。从这个角度看ON条件就像一个作用于连接后结果的WHERE条件只不过它专门负责定义两张表之间的关联关系。容易犯的错误是漏掉ON条件或写错关联字段。执行计划一旦出现200行这种爆炸式增长第一反应就应该是检查连接条件。6.2 三种JOIN的使用场景对照常用的连接类型有三种适合的场景差异很大连接类型语义典型业务场景INNER JOIN只返回两张表都能匹配上的行查有成绩记录的学生LEFT JOIN返回左表全部行右表有匹配就填充没有匹配显示NULL查所有学生及其成绩没考试的学生也要列出来RIGHT JOIN返回右表全部行左表有匹配就填充没有匹配显示NULL上面场景反过来但主流写法都习惯用LEFT JOIN一个实际的例子查所有学生和他们的成绩如果某个学生没有成绩记录也要出现在结果里SELECT student.name, score.score FROM student LEFT JOIN score ON student.stu_id score.stu_id;这条查询返回的行数至少等于学生表行数。如果学生表有5人而成绩表只有3条结果会有5行其中两行score列是NULL。有一种容易看走眼的情况在LEFT JOIN里把右表的字段放进WHERE比如SELECT student.name, score.score FROM student LEFT JOIN score ON student.stu_id score.stu_id WHERE score.score 60;这会把那两个还没有成绩的学生从结果里过滤掉因为NULL无法满足score 60。实际效果就变成了INNER JOIN。如果需求是只看成绩大于60的学生这么写没问题但如果需求是所有学生都要显示即使成绩缺失那么这个条件是错误的写法要放到ON里面去LEFT JOIN score ON student.stu_id score.stu_id AND score.score 60;这个细节几乎每次讲连接查询都会有人犯因为它混淆了连接条件和过滤条件的作用时机。6.3 连接查询的性能注意事项连接查询的性能主要看三点。第一连接字段要有索引。没有索引时数据库每取左表一行都要在右表里做一次全表扫描嵌套循环下来成本极高。这也是为什么外键字段、频繁关联的字段通常建议建索引。第二小表驱动大表。嵌套循环连接中外表越小循环次数越少。优化器通常会自己选择驱动顺序但当你使用STRAIGHT_JOIN或面对极端数据分布时可以人工干预。第三先过滤再连接。尽量让WHERE条件把单个表的数据量缩小后再参与连接。逻辑上连接是先生成笛卡尔积但优化器会优先执行条件下推把单表过滤提前。我在实际排查慢查询时习惯先用EXPLAIN看执行计划里的扫描行数。如果发现某个连接字段的type是ALL全表扫描第一件事就是检查索引。这些虽然已经超出基础语法的范畴但从开始学连接查询就带上性能意识后面会省很多事。7. 子查询的四种形态与性能辨析7.1 WHERE子查询、FROM子查询与标量子查询子查询就是查询里面套查询。按出现位置可以分为几种形态我会按实用频率排列。第一种是WHERE子查询最常见。例如查出考试成绩高于全班平均分的学生SELECT stu_id, score FROM exam_result WHERE score ( SELECT AVG(score) FROM exam_result );括号里的子查询先算出平均分外层查询再用这个值逐行比较。这个子查询只执行一次返回单个值所以也叫标量子查询。第二种是FROM子查询也叫派生表。例如先按班级算出平均分再过滤平均分大于80的班级SELECT class_id, avg_score FROM ( SELECT class_id, AVG(score) AS avg_score FROM exam_result GROUP BY class_id ) AS t WHERE avg_score 80;FROM后面括号里的结果相当于一张临时表必须给它起一个别名也就是AS t。忘记写别名会报错这是新手常见的踩坑点。第三种是SELECT子查询直接出现在SELECT列中通常用来配合外层查询做逐行计算。不过这类查询在数据量大时性能容易劣化能改成JOIN就尽量改成JOIN。第四种是EXISTS子查询用来判断是否存在而不是返回具体值。例如查出有成绩记录的学生SELECT name FROM student WHERE EXISTS ( SELECT 1 FROM exam_result WHERE exam_result.stu_id student.stu_id );子查询里写SELECT 1而不是SELECT *是一种习惯因为EXISTS只关心有没有匹配不关心返回什么列写1可以减少无谓的开销。7.2 IN与EXISTS的取舍IN和EXISTS都能表达在某个集合里但适用场景有差异。简单的集合判断比如查班级编号在某个列表里的学生SELECT * FROM student WHERE class_id IN (1, 2, 3);这种写法简单直观数据量小的时候就该这么写。但如果外层表很大、内层子查询数据量也不小情况就复杂了。经典经验是外层表数据量大、内层表数据量小时IN往往表现更好反之对于带关联条件的EXISTS子查询通常可以利用索引提前停止扫描。不过MySQL 8.0的优化器已经足够聪明很多IN子查询会被自动改写成半连接性能不一定差。我的建议是先写语义清晰的版本遇到性能问题再结合EXPLAIN去判断是否需要改写不要凭模糊的印象做出不合理的优化。FROM子查询和JOIN经常可以互换。上面按班级平均分的例子也可以通过连接加分组实现。选哪种的核心是看可读性和执行计划。对新人来说我倾向于先掌握JOIN因为它更容易看清关联关系子查询则适合表达先算出一个集合再作为条件的逻辑。8. 实操中出现的高频报错和排查习惯8.1 三条高频报错的定位方式实际写SQL时报错信息是最好的老师。我总结三个高频率报错和对应的原因。第一个报错是Every derived table must have its own alias。这是FROM子查询没有写别名导致的。MySQL要求派生表必须有一个名字所以哪怕临时表不引用也必须写AS t之类的别名。第二个报错是Invalid use of group function。这个报错的本质是用了聚合函数却不满足使用条件常见原因就是把COUNT、SUM写在WHERE里。看到这个报错先想清楚这个聚合是在分组前还是分组后如果是分组后的条件把它放进HAVING。第三个报错是Unknown column xxx in where clause。这个报错通常是列名拼写错误、表名没写对或者表达式别名被用在了WHERE里。遇到这种报错可以先查看表结构确认字段名再把WHERE阶段不能用的别名移动到ORDER BY或HAVING里。8.2 分步验证和EXPLAIN的实用习惯写复杂查询时我最推荐的调试方法是从简到繁逐层叠加。比如一条需求是统计每个班级平均分大于80分的男生人数我会分成几步来写-- 第一步先确认基础表数据 SELECT * FROM student WHERE gender 男; -- 第二步加上成绩关联 SELECT student.class_id, exam_result.score FROM student JOIN exam_result ON student.stu_id exam_result.stu_id WHERE student.gender 男; -- 第三步分组聚合 SELECT student.class_id, COUNT(*) AS cnt, AVG(exam_result.score) AS avg_score FROM student JOIN exam_result ON student.stu_id exam_result.stu_id WHERE student.gender 男 GROUP BY student.class_id; -- 第四步最后过滤分组结果 SELECT class_id, cnt, avg_score FROM ( SELECT student.class_id, COUNT(*) AS cnt, AVG(exam_result.score) AS avg_score FROM student JOIN exam_result ON student.stu_id exam_result.stu_id WHERE student.gender 男 GROUP BY student.class_id ) AS t WHERE avg_score 80;每一步都先跑通结果不对就知道是哪一步的过滤条件或聚合口径出了问题。这种习惯比一次性写好再猜问题要快得多。EXPLAIN也是排查性能问题的核心工具用法很简单只需要在查询语句前面加EXPLAINEXPLAIN SELECT ...;看结果不需要全部理解只要抓住几个关键字段type、key和rows。type如果出现ALL说明在做全表扫描数据量大时需要检查索引key显示实际用到的索引rows是预估扫描行数。数值异常大时优先怀疑连接缺少索引、WHERE条件无法用索引或子查询被反复执行。8.3 一条查询串起所有知识点最后用一个完整示例把整篇内容串起来。假设要统计每个班级中数学成绩合格的人数以及这些人数学成绩的平均分只看人数超过5人的班级按平均分从高到低排序取前3个班级SELECT class_id, COUNT(*) AS pass_cnt, AVG(score) AS avg_score FROM exam_result WHERE subject math AND score 60 GROUP BY class_id HAVING pass_cnt 5 ORDER BY avg_score DESC LIMIT 3;这条语句涵盖了WHERE行级过滤、GROUP BY分组、HAVING分组后过滤、ORDER BY排序、LIMIT分页以及COUNT、AVG两个聚合函数。你把它和最初那张执行顺序表对照着看就能感受到一条SQL在数据库里到底经历了哪些步骤。我在实际操作中最深的体会是不要急着把所有知识点一次性塞进脑子里。先把单表查询和过滤练熟再叠加分组统计之后再来啃连接和子查询。每个阶段都用上面的分步验证方法写SQL遇到报错就回到执行顺序表里找原因。基础如果打不牢后面写日报、查线上数据、做业务分析的时候都会觉得很吃力。希望这篇内容能帮你把DQL这块硬骨头啃下来少走一些我当年走过的弯路。

MySQL DQL查询实战：SELECT执行顺序、分组聚合与多表连接全解析

相关推荐

品牌短视频爆款方法论：从算法推荐到Z世代内容策略

5分钟粒度时间序列预测：ARIMA全流程实战与坑点解析

降AIGC软件横评：9类工具原理、避坑与实操流程

更多资讯

Tekla图纸二次开发入门：零基础实现自动出图与图框定制

把AI预言变成可执行的小实验：未来十年的认知框架

基于SE-ResNet的C-MAPSS航空发动机剩余寿命预测Matlab实现

Nano Banana 2登顶实测：Gemini 3.1 Flash Image多轮编辑与文字渲染深度评测

8位单片机汇编例程实战：从LED闪烁到定时器中断

多元积分复习笔记：从二重三重到曲线曲面的“正元”体系

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？