数据库性能监控是系统优化的基础，有效的监控体系需要覆盖数据库运行的各个关键环节。在资源层面，CPU使用率是需要持续关注的核心指标，理想状态应维持在70%以下，短期峰值不超过90%，过高的CPU使用往往意味着存在计算密集型的低效查询。内存监控要特别关注缓冲池命中率，对于OLTP系统该指标应保持在95%以上，低于90%则表明内存配置可能不足或存在全表等低效操作。磁盘IO监控包括读写吞吐量和延迟，随机读延迟超过20ms就需要引起警惕，可能是磁盘性能瓶颈或索引缺失的信号。网络吞吐量对于分布式数据库尤为重要，需要监控节点间的数据传输量及延迟，异常的网络抖动往往会导致分布式事务超时。除了硬件资源，数据库内部状态同样需要监控，包括连接数、锁等待、临时表使用等，这些指标能直接反映SQL执行效率问题。完善的监控系统应该具备趋势分析能力，通过对比历史数据识别性能退化，比如某个查询的执行时间随时间逐渐增加，可能是数据量增长导致原有索引失效的信号。

SQL调优的首要任务是识别问题查询，慢查询日志是最直接的诊断工具。配置合理的慢查询阈值非常重要，对于Web应用通常设置为100-500ms，金融交易系统可能需要更严格的50ms标准。收集到的慢查询需要进一步分析执行计划，理解数据库优化器选择的访问路径。执行计划中的全表（Full Table Scan）通常是性能问题的首要嫌疑，特别是在大表上出现时。索引（Index Scan）比全表高效，但在某些情况下索引覆盖（Covering Index Scan）能带来更大提升，因为它可以规避回表操作。多表连接顺序不当是另一个常见问题，执行计划中表的连接顺序应该使中间结果集尽可能小。子查询物化可能导致不必要的临时表创建，在MySQL中尤其常见，改写为JOIN往往能显著提升性能。执行计划中的额外信息（Extra列）也值得关注，"Using temporary"表示使用了临时表，"Using filesort"表示需要额外排序，这些都是潜在的优化点。

索引优化是SQL调优中最有效的手段之一，但需要遵循科学的设计原则。单列索引适合高选择性的字段，比如用户表的手机号或邮箱字段，这类字段上的等值查询能快速定位少量数据。复合索引需要考虑字段顺序，最左前缀原则决定了索引的可用性，将高频查询条件和高选择性字段放在前面是通用准则。覆盖索引通过包含查询所需的所有字段，规避了回表操作，对于频繁查询的列组合特别有效。索引并非越多越好，每个索引都会增加写操作的开销，通常建议表的索引数量控制在5个以内。定期分析索引使用情况很重要，长期未使用的索引应该考虑删除，规避维护开销。部分数据库支持函数索引和部分索引，这些特性可以用来优化特殊场景，比如只对某个状态的数据建立索引。索引统计信息的及时更新也很关键，过时的统计信息会导致优化器选择低效的执行计划。

SQL重写技巧能在不改变数据库结构的情况下显著提升性能。使用EXISTS代替IN在多数情况下更高效，特别是当子查询返回大量数据时。规避在WHERE条件中对字段使用函数或运算，这会导致索引失效，比如WHERE YEAR(create_time)=2023应该改写为范围查询。LIMIT分页查询在大偏移量时性能很差，可以采用"记住上次位置"的方式优化，或者使用覆盖索引先获取ID再回查。UNION ALL比UNION高效，除非确实需要去重，因为UNION需要额外的排序去重操作。JOIN查询要确保连接字段有合适的索引，并且小表驱动大表的原则通常适用。临时表在复杂查询中有时能简化逻辑，但要注意规避多层嵌套的临时表操作。批量操作代替循环单条操作能大幅减少网络往返和SQL解析开销，比如使用INSERT的多VALUES语法。

数据库配置调优需要根据工作负荷特点进行调整。内存分配是最关键的配置项，缓冲池大小通常设置为可用物理内存的60-80%，但需要为操作系统和其他应用保留足够内存。连接池大小应该与业务并发量匹配，过小会导致请求排队，过大则增加上下文切换开销。排序缓冲区、临时表空间等会话级内存参数需要根据典型查询需求设置，对于报表类应用可以适当调大。并发控制参数如锁超时时间、死锁检测间隔需要衡量响应速度和系统吞吐量。日志相关配置会影响IO压力，在保证必要审计信息的前提下，可以适当调整日志刷盘频率。定期维护操作如统计信息更新、索引重建的计划需要避开业务高峰，大型表的维护可以考虑分片进行。

高级调优技术可以解决特定场景下的性能难题。对于热点数据问题，可以考虑引入缓存层，但需要注意缓存一致性的维护。分库分表是应对单机容量限制的终极方案，但会引入分布式事务等复杂度，需要谨慎评估。读写分离将查询负荷分散到多个副本，适合读多写少的场景。物化视图能预先计算复杂查询结果，适合数据仓库和报表系统。查询重写插件可以拦截和优化应用发出的SQL，特别适合难以修改遗留代码的情况。执行计划绑定可以稳定关键查询的性能，规避统计信息变化导致的性能波动。并行查询利用多核CPU加速大查询，但需要合理设置并行度规避资源争用。

性能优化需要建立持续改进的机制。基准测试是衡量优化效果的必要手段，应该在生产环境类似的数据集上进行，记录优化前后的关键指标对比。性能基线的建立有助于快速识别异常，当系统指标偏离基线时可以及时预警。容量规划需要基于业务增长趋势，提前做好资源扩容准备，规避性能突然恶化。定期进行健康检查，包括索引碎片、表空间使用、过期统计信息等问题，防患于未然。建立性能优化的知识库，记录常见问题的解决方案，加速未来类似问题的处理。最后要记住，任何优化都应该以业务需求为导向，规避过度优化带来的复杂度和维护成本。

实战案例能直观展示优化效果。某电商后台的商品搜索接口原来需要800ms，分析发现是由于OR条件导致索引失效，通过改写为UNION ALL并使用覆盖索引，响应时间降至120ms。某金融系统的对账作业原来需要4小时完成，通过将单条处理改为批量操作，并增加临时表减少重复计算，时间缩短到40分钟。内容管理系统的列表分页在大偏移量时超时，通过改用"记住位置"的分页方式，性能提升20倍以上。这些案例表明，合理的性能监控结合针对性的调优手段，能够解决大多数数据库性能问题，为业务系统提供有力的数据支撑。