Unknown column错误需检查字段名、大小写、数据库上下文；Invalid default value错误因严格模式下插入NULL/空字符串，应修正数据校验；type=ALL表示全表扫描，需建索引或更新统计信息；深分页应改用游标分页避免filesort。
mysql查询报错：Unknown column、Invalid default value这类错误怎么快速定位
这类错误基本不是SQL逻辑问题，而是表结构与sql语句不匹配导致的。比如执行 SELECT user_name FROM users WHERE created_at > '2024-01-01' 报 Unknown column 'user_name' in 'field list'，说明当前表根本没有这个字段——可能是字段名拼错、大小写敏感（在linux上lower_case_table_names=0时列名区分大小写）、或者连错了数据库。
排查步骤：
- 用
DESCRIBE或SHOW COLUMNS FROM确认字段真实名称和类型 - 检查是否在错误的数据库上下文执行（
select database()查当前库） - 若用ORM或模板拼接SQL，确认变量注入后没多出空格或引号（如生成出
'user_name '） -
Invalid default value for 'xxx'通常出现在严格模式（STRICT_TRANS_TABLES）开启时对NOT NULL字段插入NULL或空字符串，临时绕过可用SET sql_mode = ''，但应修正应用层数据校验
EXPLaiN结果里type=ALL、rows远大于实际返回行数意味着什么
type=ALL 表示全表扫描，是性能杀手；而 rows 字段显示优化器预估需要检查的行数，如果它比实际结果集大几个数量级，说明索引没被正确使用或统计信息过期。
常见原因和应对：
- WHERE条件字段没有索引，或用了函数/表达式导致索引失效（如
WHERE date(created_at) = '2024-01-01'→ 改成WHERE created_at >= '2024-01-01' AND created_at ） - 联合索引顺序不匹配：
INDEX(a,b,c)能用于WHERE a=1 AND b>10，但不能用于WHERE b=10单独查询 - 字符集或排序规则不一致：关联字段一个是
utf8mb4_0900_as_cs，另一个是utf8mb4_general_ci，会导致无法走索引 - 统计信息陈旧：执行
ANALYZE TABLE更新行数、索引分布等元数据
ORDER BY + LIMIT 在大偏移量下变慢，如何避免filesort和深分页
像 SELECT * FROM orders ORDER BY created_at DESC LIMIT 10000, 20 这类语句，MySQL必须先排序全部匹配行，再跳过前10000条——即使有索引，filesort 仍可能触发磁盘临时表。
更高效的做法：
- 用游标分页替代偏移分页：记录上一页最后一条的
created_at值，下一页查WHERE created_at - 确保
ORDER BY字段在索引最左位，且方向一致（INDEX(created_at DESC)在8.0+支持降序索引） - 避免
SELECT *，只查必要字段，减少排序和传输开销 - 如果业务允许，加覆盖索引：如
INDEX(status, created_at, id, user_id)，让SELECT id,user_id FROM ... WHERE status='paid' ORDER BY created_at DESC LIMIT 20完全走索引不回表
慢查询日志里出现Sending data状态持续很久，是不是IO瓶颈
不是。Sending data 状态实际代表“正在处理查询结果”，包括聚合、排序、生成临时表、甚至往网络缓冲区写数据的过程，并非单纯磁盘读取。它长往往暴露的是计算密集型操作，比如没走索引的大范围GROUP BY、子查询嵌套过深、或jsON字段频繁解析。
诊断建议：
- 用
SHOW PROFILE FOR QUERY查看各阶段耗时，确认是否卡在Creating sort index或Copying to tmp table - 检查是否用了
SELECT DISTINCT或GROUP BY配合未索引字段，考虑加索引或改用GROUP BY字段前置的联合索引 - 避免在WHERE中用
json_EXTRACT(json_col, '$.field') = 'val'，改用生成列+索引：ALTER TABLE t ADD COLUMN field_val VARCHAR(64) AS (JSON_UNQUOTE(JSON_EXTRACT(json_col, '$.field'))) STOred，再建索引 - 确认是否启用了
tmp_table_size和max_heap_table_size过小，导致本该内存完成的临时表被迫落盘
索引设计和查询重写往往比调参数见效更快，但最容易被忽略的是字段类型隐式转换——比如 user_id 是 BIGINT，却用字符串 '123' 查询，会导致索引失效，这种细节在EXPLAIN里看不出，只能靠肉眼核对条件类型。