执行报错时如何利用分析数据库慢查询排查_SQL语法纠错技巧

%开头的LIKE无法走索引导致全表扫描应改用LIKE abc%、函数索引、全文索引或ES列名错误多因大小写、反引号缺失或别名作用域问题GROUP BY报错源于ONLY_FULL_GROUP_BY模式需合规改写SQL。MySQL 慢查询日志里看到 SELECT ... WHERE ... LIKE %xxx为什么执行还慢因为 % 开头的 like 无法走索引哪怕字段上有索引也白搭。这不是语法错是语义陷阱——mysql 优化器直接放弃使用索引做范围扫描转为全表扫描。用 EXPLAIN 看 type 字段如果是 ALL基本就是全表扫了把 LIKE %abc 改成 LIKE abc% 才可能命中索引前提是索引列在最左前缀真要查后缀考虑加 REVERSE() 函数建函数索引MySQL 8.0比如 CREATE INDEX idx_rev_name ON t1 ((REVERSE(name)))查时写 WHERE REVERSE(name) LIKE REVERSE(abc) %模糊匹配需求多别硬扛上 全文索引 或 ES 更实际执行报错 ERROR 1054 (42S22): Unknown column xxx in where clause但字段明明存在常见于大小写混用、反引号缺失或别名作用域错乱。MySQL 在严格模式下对列名解析很较真尤其跨子查询或 JOIN 时。检查是否用了关键字当列名比如 order、group必须用反引号包住order子查询里定义的别名在外部 WHERE 中不可见得挪到 HAVING 或外层再过滤确认表别名有没有写错比如写了 FROM users u后面却用 users.id 而不是 u.id大小写敏感取决于系统变量 lower_case_table_names但列名一般不区分大小写不过视图或临时表里若显式用了大写别名就得严格匹配为什么 GROUP BY 报错 ERROR 1055而同样 SQL 在另一台机器上能跑这是 MySQL 5.7 默认开启 ONLY_FULL_GROUP_BY SQL 模式导致的不是语法错是合规性校验变严了。它要求 SELECT 列要么在 GROUP BY 中要么是聚合函数包裹的。临时绕过执行 SET sql_mode(SELECT REPLACE(sql_mode,ONLY_FULL_GROUP_BY,));仅当前会话长期方案改 SQL把非聚合字段从 SELECT 中去掉或补进 GROUP BY例如 SELECT user_id, MAX(created_at) FROM log GROUP BY user_id注意 ORM 自动生成的 SQL如 Django 的 .values()容易触发这个错误得看它生成的字段是否都出现在 GROUP BY 里别盲目关全局模式它能帮你提前发现逻辑歧义比如你本意是按用户分组却顺手 SELECT 了用户的 email 和 phone而一个用户有多条记录时这两个字段值不确定选哪条ORDER BY 加了索引还是慢EXPLAIN 显示 Using filesortUsing filesort 不代表一定慢但说明没用上索引排序能力。根本原因是排序字段和 WHERE 条件字段没构成“最左前缀”连续索引。 唱鸭 音乐创作全流程的AI自动作曲工具集 AI 辅助作词、AI 自动作曲、编曲、混音于一体