MySQL默认不开启慢查询日志，需检查slow_query_log是否为ON、long_query_time阈值是否合理，并确认log_output方式及日志路径或表位置。
怎么看慢查询日志是否开启
MySQL 默认不开启慢查询日志，得先确认配置是否生效。关键看两个系统变量：slow_query_log 和 long_query_time。前者必须为 ON，后者决定“慢”的阈值（单位秒，支持小数，比如 0.5 表示超过 500ms 就记）。
实操建议：
- 用
SHOW VARIABLES LIKE 'slow_query_log'和SHOW VARIABLES LIKE 'long_query_time'直接查当前值 - 线上环境别直接改
SET GLOBAL slow_query_log = ON，优先走配置文件（my.cnf），避免重启失效或误操作 - 注意
log_output的值：如果设成FILE，日志写磁盘，路径由slow_query_log_file指定；设成TABLE则写入mysql.slow_log表——后者方便 SQL 查询分析，但有性能开销，不建议长期开启
如何定位具体是哪条 SQL 在拖慢服务
慢查询日志本身只记录执行时间超限的语句，但缺乏上下文。光看 SQL 文本容易误判，比如同一条 SELECT * FROM orders WHERE user_id = ?，参数不同可能走不同索引、甚至全表扫描。
实操建议：
- 启用
log_queries_not_using_indexes（谨慎！高并发下日志量爆炸），能抓到没走索引的查询，但别长期开着 - 配合
pt-query-digest工具解析慢日志：pt-query-digest /var/lib/mysql/slow.log，它会自动聚合、排序、给出执行次数、平均时间、锁等待等维度 - 重点看
Rows_examined和Rows_sent的比值——如果查了 10 万行只返回 1 行，大概率缺索引或条件没打在索引列上
EXPLAIN 看懂了但还是不会优化
EXPLAIN 输出里最需盯紧三列：type（访问类型）、key（实际用的索引）、Extra（额外动作）。常见陷阱不是看不懂字段，而是忽略隐式转换和索引失效场景。
华友协同办公自动化OA系统
下载
华友协同办公管理系统(华友OA)，基于微软最新的.net 2.0平台和SQL Server数据库，集成强大的Ajax技术，采用多层分布式架构，实现统一办公平台，功能强大、价格便宜，是适用于企事业单位的通用型网络协同办公系统。 系统秉承协同办公的思想，集成即时通讯、日记管理、通知管理、邮件管理、新闻、考勤管理、短信管理、个人文件柜、日程安排、工作计划、工作日清、通讯录、公文流转、论坛、在线调查、
实操建议：
-
type出现ALL或index基本等于全表/全索引扫描，优先检查WHERE条件是否用了函数（如WHERE DATE(create_time) = '2024-01-01'）、或者对索引列做了运算（WHERE id + 1 = 100） -
key为空但possible_keys有值？说明优化器认为走索引不如全扫——可能是因为数据分布倾斜（比如某值占 90%），也可能是统计信息过期，可手动执行ANALYZE TABLE table_name -
Extra里出现Using filesort或Using temporary，意味着排序或分组没走索引，要检查ORDER BY和GROUP BY字段是否包含在联合索引最左前缀中
加了索引查询还是慢，为什么
索引不是银弹。尤其在线上高频更新的表上，索引越多，写放大越严重，而且 MySQL 对联合索引的匹配有严格顺序要求。
实操建议：
- 避免给低区分度字段建索引（如
status只有 0/1，加索引基本无效） - 联合索引字段顺序必须匹配查询模式：
INDEX(a,b,c)能加速WHERE a=1 AND b=2，但对WHERE b=2无效；如果常查b单独条件，得另建索引 - 注意索引长度限制：InnoDB 单索引长度上限约 767 字节（utf8mb4 下约 191 个字符），
VARCHAR(500)字段直接建索引会截断，导致查询时无法命中 - 上线前务必在从库或影子库跑
EXPLAIN FORMAT=JSON，看used_columns和key_parts是否符合预期——生产环境优化器行为可能和测试库不一致
真实线上慢查往往卡在“以为优化到位了”那一步：索引建了、EXPLAIN 看着没问题、QPS 也稳，但某天突然响应毛刺。这时候得回头再核对 Rows_examined 增长趋势、检查是否有未被慢日志捕获的短时尖峰查询（long_query_time 设太高）、或者应用层批量请求触发了锁竞争。
