数据库慢查询日志是定位性能瓶颈的直接入口，当你发现应用响应变慢，首先就该检查慢查询日志。它记录了执行时间超过指定阈值（如默认10秒）的SQL语句，通过分析这些语句，你能快速找出哪些查询拖慢了系统。具体操作是开启慢查询日志功能，设置阈值，然后定期分析日志文件。例如在MySQL中，你可以在配置文件中设置slow_query_log=ON、long_query_time=2（单位秒）来开启并定义慢查询阈值，之后使用mysqldumpslow工具或Percona的pt-query-digest进行日志分析，找出执行次数多、耗时长的查询。

慢查询日志的核心分析维度：不只是时间

分析慢查询日志时，不能只看执行时间。你需要关注多个维度：查询执行时间、锁定时间、返回行数、扫描行数以及执行频率。例如，一个查询执行时间2秒，但锁定时间占了1.5秒，这可能是事务竞争导致的；另一个查询返回10行却扫描了10万行，说明索引效率低下。使用pt-query-digest工具可以生成详细报告，它会将查询归类，统计总耗时、平均耗时、占比等，帮你快速定位最消耗资源的查询模式。同时，结合EXPLAIN命令分析查询执行计划，查看索引使用情况、表连接顺序和扫描类型，这是从日志到具体优化步骤的关键桥梁。

索引优化原则：如何建立有效的索引

索引优化的核心是减少数据扫描量。首先，为WHERE子句、JOIN条件和ORDER BY/GROUP BY的列创建索引。例如，查询SELECT * FROM users WHERE status='active' ORDER BY created_at;，应在status和created_at上建立复合索引(status, created_at)。其次，遵循最左前缀原则：复合索引(a, b, c)可以支持查询条件为a、a,b或a,b,c的查询，但无法支持单独查询b或c。另外，避免过度索引，索引会降低写操作性能并占用存储空间；对于区分度低的列（如性别），索引效果甚微。使用覆盖索引（索引包含所有查询字段）可以避免回表，大幅提升性能。

常见慢查询场景与索引优化实例

场景一：全表扫描。当查询缺少合适索引时，会导致全表扫描。例如，SELECT * FROM orders WHERE customer_id=100 AND year(created_at)=2023;，如果在customer_id和created_at上没有索引，就会扫描整个表。优化方案是创建复合索引(customer_id, created_at)，并避免在索引列上使用函数，改写查询为WHERE customer_id=100 AND created_at BETWEEN '2023-01-01' AND '2023-12-31'。

场景二：索引失效。使用LIKE '%keyword%'、函数操作（如WHERE DATE(created_at)='2023-10-01'）或类型转换会导致索引失效。解决方案是调整查询逻辑，例如将函数操作移到右侧：WHERE created_at >= '2023-10-01' AND created_at < '2023-10-02'。

场景三：排序和分页慢。查询SELECT * FROM logs ORDER BY timestamp DESC LIMIT 1000,20;，当偏移量大时，数据库需要先扫描并丢弃大量行。优化方法是在timestamp上建立索引，并考虑使用游标分页：WHERE timestamp < 'last_timestamp' ORDER BY timestamp DESC LIMIT 20。

-- 示例：创建优化索引
ALTER TABLE orders ADD INDEX idx_customer_created (customer_id, created_at);
ALTER TABLE logs ADD INDEX idx_timestamp (timestamp);

高级优化策略：联合索引与索引选择性

对于复杂查询，联合索引设计至关重要。考虑查询SELECT * FROM products WHERE category='electronics' AND price>1000 ORDER BY popularity DESC;，最优索引是(category, price, popularity)。这样索引可以高效过滤category和price，并直接按popularity排序，避免额外排序操作。索引选择性是指不重复的索引值与总行数的比例，高选择性（接近1）的列更适合作为索引前列。例如，在users表中，email列比country列选择性更高，应优先放在复合索引前面。你可以通过SELECT COUNT(DISTINCT column)/COUNT(*) FROM table;计算选择性。

监控与持续优化：建立性能基线

优化不是一劳永逸的。你需要建立性能监控体系，定期检查慢查询日志和索引使用情况。使用数据库内置的监控工具，如MySQL的Performance Schema或sys schema，跟踪查询性能变化。例如，查询SELECT * FROM sys.schema_unused_indexes;可以找出未使用的索引，考虑删除以节省资源。同时，设置告警机制，当慢查询数量或平均响应时间突增时及时通知。建议每周或每月进行一次深度分析，根据业务变化调整索引结构，确保数据库持续高效运行。

避免常见误区：索引不是万能药

索引能提升查询性能，但错误使用会适得其反。误区一：盲目添加所有查询列到索引。这会导致索引过大，降低写速度。应只添加必要的列。误区二：忽视数据更新频率。对于频繁更新的表，索引维护成本高，需权衡读写比例。误区三：仅依赖单列索引。复合索引往往更高效。最后，记住优化顺序：先分析慢查询定位问题，再设计或调整索引，然后重写低效SQL，最后考虑硬件或配置调整。通过系统化方法，你能将数据库性能提升一个数量级。