业界统计，80%的性能瓶颈最终定位在数据库层——SQL慢查询、索引缺失、连接池耗尽、锁竞争是银行系统最常见的四类数据库性能问题。数据库调优要从SQL→索引→连接池→实例参数逐层递进。
先从慢查询日志入手，找到压测期间耗时最长的Top 10 SQL。常见的SQL问题：全表扫描（缺失索引）、隐式类型转换（导致索引失效）、大表JOIN未用小表驱动大表、SELECT *返回不必要字段。
检查执行计划（EXPLAIN），确保关键SQL使用最优索引。银行系统的常见索引陷阱：联合索引列顺序错误（最左前缀原则）、函数索引缺失（WHERE DATE(create_time)=...）、索引过多导致写入变慢。
应用服务器的数据库连接池是并发能力的直接瓶颈。连接池太小→请求排队超时；连接池太大→数据库连接数耗尽。经验公式：连接池大小 = 最大并发线程数 × 单线程平均SQL执行时间。HikariCP/Druid的常用配置：maximumPoolSize=(CPU核心数×2)+磁盘数。
MySQL的InnoDB缓冲池（innodb_buffer_pool_size）应设为可用内存的70-80%。Oracle的SGA/PGA需根据连接数和SQL复杂度调整。银行核心系统的数据库参数需DBA联合性能测试团队共同确认。
操作：压测期间开启数据库慢查询日志（long_query_time=0.5秒），同时用MySQL Exporter + Grafana监控QPS、连接数和慢查询趋势。
操作：阶梯式增加并发数，观察连接池的使用率曲线。当连接池使用率达到80%且出现等待计数时，说明连接池即将成为瓶颈，需要扩容或优化SQL降低执行时间。