MySQL性能优化实战

马哥Linux运维 2025-09-17 305

描述

MySQL性能优化实战：从慢查询到亿级数据优化的进阶之路

你是否遇到过这些场景：凌晨3点被告警电话吵醒，数据库CPU飙到100%？一条简单的查询语句要跑30秒？明明加了索引，查询还是慢如蜗牛？

作为一名运维工程师，我在过去8年里处理过无数MySQL性能问题。今天，我将分享那些让我"踩坑无数"却最终练就一身本领的实战经验。这篇文章不讲虚的理论，只分享真实场景下的优化技巧。

一、性能问题诊断：找到瓶颈比优化更重要

1.1 慢查询日志：性能问题的第一手证据

很多运维同学知道慢查询日志，但真正会用的不多。我见过太多人开启了慢查询却从不分析，白白浪费了这个强大的工具。

快速开启慢查询日志：

-- 查看当前慢查询配置
SHOW VARIABLES LIKE '%slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

-- 动态开启慢查询日志（立即生效，重启失效）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL long_query_time = 1;  -- 超过1秒的查询记录下来
SET GLOBAL log_queries_not_using_indexes = 'ON';  -- 记录未使用索引的查询

慢查询分析神器 - pt-query-digest：

# 安装percona-toolkit
wget https://downloads.percona.com/downloads/percona-toolkit/3.5.0/binary/tarball/percona-toolkit-3.5.0_x86_64.tar.gz
tar -xzvf percona-toolkit-3.5.0_x86_64.tar.gz

# 分析慢查询日志，找出TOP 10问题SQL
pt-query-digest /var/log/mysql/slow.log > analyze_result.txt

# 只看执行时间最长的10条SQL
pt-query-digest --limit=10 --order-by=Query_time:sum /var/log/mysql/slow.log

实战技巧： 我通常会设置一个定时任务，每天凌晨自动分析前一天的慢查询日志，并将结果发送到邮箱。这样能第一时间发现潜在的性能问题。

1.2 实时监控：抓住性能问题的现行犯

当数据库突然变慢时，如何快速定位问题？这几个命令是我的救命稻草：

-- 查看当前正在执行的SQL
SHOW PROCESSLIST;
-- 或者使用更详细的
SELECT * FROM information_schema.processlist 
WHERE command != 'Sleep' 
ORDER BY time DESC;

-- 查看InnoDB引擎状态（包含死锁信息）
SHOW ENGINE INNODB STATUSG

-- 查看表锁等待情况
SELECT * FROM information_schema.innodb_lock_waits;

-- 查看事务执行情况
SELECT * FROM information_schema.innodb_trx 
WHERE trx_state = 'RUNNING' 
ORDER BY trx_started;

实战案例： 上个月，我们的订单系统突然响应变慢。通过SHOW PROCESSLIST发现有200多个查询在等待表锁。追查后发现是一个开发同学在生产环境执行了ALTER TABLE操作。教训：任何DDL操作都要在业务低峰期执行，并使用pt-online-schema-change等工具。

1.3 性能指标监控：构建MySQL健康体检系统

#!/bin/bash
# MySQL性能监控脚本 monitor_mysql.sh

MYSQL_USER="monitor"
MYSQL_PASS="your_password"
MYSQL_HOST="localhost"

# 监控QPS (每秒查询数)
QPS=$(mysql -u${MYSQL_USER} -p${MYSQL_PASS} -h${MYSQL_HOST} -e "SHOW GLOBAL STATUS LIKE 'Questions';" -ss | awk '{print $2}')
sleep 1
QPS2=$(mysql -u${MYSQL_USER} -p${MYSQL_PASS} -h${MYSQL_HOST} -e "SHOW GLOBAL STATUS LIKE 'Questions';" -ss | awk '{print $2}')
echo "当前QPS: $((QPS2-QPS))"

# 监控连接数
mysql -u${MYSQL_USER} -p${MYSQL_PASS} -h${MYSQL_HOST} -e "
SELECT 
    count(*) as total_connections,
    sum(case when command='Sleep' then 1 else 0 end) as sleeping,
    sum(case when command!='Sleep' then 1 else 0 end) as active
FROM information_schema.processlist;"

# 监控缓冲池命中率
mysql -u${MYSQL_USER} -p${MYSQL_PASS} -h${MYSQL_HOST} -e "
SELECT 
    (1 - (Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests)) * 100 as hit_ratio
FROM (
    SELECT 
        variable_value as Innodb_buffer_pool_reads 
    FROM information_schema.global_status 
    WHERE variable_name = 'Innodb_buffer_pool_reads'
) a, (
    SELECT 
        variable_value as Innodb_buffer_pool_read_requests 
    FROM information_schema.global_status 
    WHERE variable_name = 'Innodb_buffer_pool_read_requests'
) b;"

二、索引优化：让查询飞起来的核心技术

2.1 索引设计原则：不是越多越好

很多人认为索引越多越好，这是个严重的误区。过多的索引会导致：

• 写入性能下降（每次INSERT/UPDATE都要维护索引）

• 占用更多磁盘空间

• 优化器选择困难，可能选错索引

索引设计黄金法则：

-- 案例：电商订单表
CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    order_no VARCHAR(32) NOT NULL,
    status TINYINT NOT NULL DEFAULT 0,
    total_amount DECIMAL(10,2) NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    
    -- 索引设计
    UNIQUE KEY uk_order_no (order_no),  -- 订单号唯一索引
    KEY idx_user_status (user_id, status, created_at),  -- 联合索引
    KEY idx_created_at (created_at)  -- 时间索引用于范围查询
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 为什么这样设计？
-- 1. order_no经常用于精确查询，设置唯一索引
-- 2. user_id + status 经常一起查询，建立联合索引
-- 3. created_at用于订单时间范围查询

2.2 索引失效的坑：明明有索引为什么不走？

-- 创建测试表
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    email VARCHAR(100),
    KEY idx_name (name),
    KEY idx_age (age)
);

-- 索引失效场景1：类型不匹配
-- 错误示例（age是INT类型，用字符串查询）
EXPLAIN SELECT * FROM users WHERE age = '25';  -- 可能不走索引

-- 正确示例
EXPLAIN SELECT * FROM users WHERE age = 25;

-- 索引失效场景2：使用函数
-- 错误示例
EXPLAIN SELECT * FROM users WHERE YEAR(created_at) = 2024;  -- 不走索引

-- 正确示例
EXPLAIN SELECT * FROM users WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01';

-- 索引失效场景3：最左前缀原则
-- 假设有联合索引 idx_abc(a,b,c)
-- 走索引：WHERE a=1 AND b=2
-- 走索引：WHERE a=1
-- 不走索引：WHERE b=2 AND c=3
-- 部分走索引：WHERE a=1 AND c=3 (只用到a列的索引)

2.3 索引优化实战：一个真实的优化案例

上个季度，我优化了一个查询从30秒降到0.1秒，这里分享优化过程：

-- 原始慢查询（执行时间：30秒）
SELECT 
    o.order_no, o.total_amount, u.name, p.product_name
FROM orders o
JOIN users u ON o.user_id = u.id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE o.created_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
    AND o.status = 1
    AND u.city = '北京';

-- 使用EXPLAIN分析
EXPLAIN SELECT ...;
-- 发现问题：orders表全表扫描，没有合适的索引

-- 优化方案1：添加合适的索引
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);
ALTER TABLE users ADD INDEX idx_city (city);

-- 优化方案2：改写SQL，先缩小结果集
SELECT 
    o.order_no, o.total_amount, u.name, p.product_name
FROM (
    SELECT * FROM orders 
    WHERE status = 1 
    AND created_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
    LIMIT 1000
) o
JOIN users u ON o.user_id = u.id AND u.city = '北京'
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id;

-- 执行时间：0.1秒

三、查询优化：写出高性能SQL的艺术

3.1 JOIN优化：小表驱动大表

-- 假设 users 表有100万条记录，orders 表有1000万条记录
-- 需要查询北京用户的订单

-- 低效写法（大表驱动小表）
SELECT o.*, u.name 
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE u.city = '北京';

-- 高效写法（小表驱动大表）
SELECT o.*, u.name
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE u.city = '北京';

-- 更好的写法（使用子查询先过滤）
SELECT o.*, u.name
FROM orders o
INNER JOIN (
    SELECT id, name FROM users WHERE city = '北京'
) u ON o.user_id = u.id;

3.2 分页优化：大偏移量的解决方案

-- 问题：深度分页性能差
-- 当offset很大时，MySQL需要扫描大量不需要的行
SELECT * FROM orders ORDER BY id LIMIT 1000000, 20;  -- 需要扫描1000020行

-- 优化方案1：使用覆盖索引
SELECT * FROM orders o
INNER JOIN (
    SELECT id FROM orders ORDER BY id LIMIT 1000000, 20
) t ON o.id = t.id;

-- 优化方案2：使用游标方式（推荐）
-- 记住上一页最后一条记录的id
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 20;

-- 优化方案3：使用延迟关联
SELECT * FROM orders o
INNER JOIN (
    SELECT id FROM orders 
    WHERE created_at > '2024-01-01'
    ORDER BY id 
    LIMIT 1000000, 20
) t USING(id);

3.3 子查询优化：EXISTS vs IN vs JOIN

-- 场景：查找有订单的用户
-- 表数据量：users 10万，orders 100万

-- 方法1：使用IN（当子查询结果集小时效率高）
SELECT * FROM users 
WHERE id IN (SELECT DISTINCT user_id FROM orders);

-- 方法2：使用EXISTS（当外表小，内表大时效率高）
SELECT * FROM users u
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);

-- 方法3：使用JOIN（通常性能最好）
SELECT DISTINCT u.* FROM users u
INNER JOIN orders o ON u.id = o.user_id;

-- 性能对比脚本
SET @start = NOW(6);
-- 执行查询
SELECT COUNT(*) FROM users WHERE id IN (SELECT user_id FROM orders);
SELECT TIMESTAMPDIFF(MICROSECOND, @start, NOW(6)) / 1000000 as execution_time;

四、参数调优：榨干硬件的每一分性能

4.1 内存参数优化

-- 查看当前buffer pool大小
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

-- 查看buffer pool命中率（应该大于95%）
SELECT 
    (1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100 
    as buffer_pool_hit_ratio
FROM (
    SELECT variable_value Innodb_buffer_pool_reads 
    FROM information_schema.global_status 
    WHERE variable_name = 'Innodb_buffer_pool_reads'
) a, (
    SELECT variable_value Innodb_buffer_pool_read_requests 
    FROM information_schema.global_status 
    WHERE variable_name = 'Innodb_buffer_pool_read_requests'
) b;

my.cnf 优化配置示例：

[mysqld]
# 内存优化（假设服务器有64GB内存）
innodb_buffer_pool_size = 48G  # 物理内存的75%
innodb_buffer_pool_instances = 8  # CPU核数
innodb_log_file_size = 2G  # 大事务场景可以设置更大
innodb_flush_log_at_trx_commit = 2  # 性能和安全的平衡
innodb_flush_method = O_DIRECT  # 避免双重缓存

# 连接优化
max_connections = 2000
max_connect_errors = 100000
connect_timeout = 10

# 查询缓存（MySQL 8.0已移除）
query_cache_type = 0  # 建议关闭，用Redis代替

# 临时表优化
tmp_table_size = 256M
max_heap_table_size = 256M

# 慢查询
slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 1

4.2 硬件层面的优化建议

基于我的经验，硬件优化的性价比排序：

1. SSD > 内存 > CPU：SSD对数据库性能提升最明显

2. RAID配置：RAID10 是最佳选择（性能和安全的平衡）

3. 网络：万兆网卡，减少网络延迟

五、架构优化：从单机到分布式的进化

5.1 读写分离：最简单有效的扩展方案

# Python实现读写分离示例
import random
import pymysql

class DBRouter:
    def __init__(self):
        # 主库（写）
        self.master = pymysql.connect(
            host='master.db.com',
            user='root',
            password='password',
            database='mydb'
        )
        
        # 从库池（读）
        self.slaves = [
            pymysql.connect(host='slave1.db.com', ...),
            pymysql.connect(host='slave2.db.com', ...),
        ]
    
    def execute_write(self, sql, params=None):
        """写操作走主库"""
        with self.master.cursor() as cursor:
            cursor.execute(sql, params)
            self.master.commit()
            return cursor.lastrowid
    
    def execute_read(self, sql, params=None):
        """读操作随机选择从库"""
        slave = random.choice(self.slaves)
        with slave.cursor() as cursor:
            cursor.execute(sql, params)
            return cursor.fetchall()
    
    def execute_read_master(self, sql, params=None):
        """强制读主库（解决延迟问题）"""
        with self.master.cursor() as cursor:
            cursor.execute(sql, params)
            return cursor.fetchall()

# 使用示例
db = DBRouter()
# 写入订单
order_id = db.execute_write(
    "INSERT INTO orders (user_id, amount) VALUES (%s, %s)",
    (123, 99.99)
)
# 立即查询需要读主库（避免主从延迟）
order = db.execute_read_master(
    "SELECT * FROM orders WHERE id = %s", 
    (order_id,)
)

5.2 分库分表：应对亿级数据的终极方案

-- 分表方案示例：按用户ID取模分表
-- 创建16个订单表
CREATE TABLE orders_0 LIKE orders_template;
CREATE TABLE orders_1 LIKE orders_template;
-- ... 一直到 orders_15

-- 路由算法（应用层实现）
-- table_index = user_id % 16
-- 如 user_id = 12345, 则数据存在 orders_9 表中

# Python分表路由实现
class ShardingRouter:
    def __init__(self, shard_count=16):
        self.shard_count = shard_count
        
    def get_table_name(self, base_name, sharding_key):
        """根据分片键计算表名"""
        shard_index = sharding_key % self.shard_count
        return f"{base_name}_{shard_index}"
    
    def insert_order(self, user_id, order_data):
        table_name = self.get_table_name('orders', user_id)
        sql = f"INSERT INTO {table_name} (user_id, ...) VALUES (%s, ...)"
        # 执行SQL
        
    def query_user_orders(self, user_id):
        """查询用户订单（定位到具体分表）"""
        table_name = self.get_table_name('orders', user_id)
        sql = f"SELECT * FROM {table_name} WHERE user_id = %s"
        # 执行查询
        
    def query_order_by_id(self, order_id):
        """根据订单ID查询（需要扫描所有分表）"""
        results = []
        for i in range(self.shard_count):
            table_name = f"orders_{i}"
            sql = f"SELECT * FROM {table_name} WHERE order_id = %s"
            # 并发查询所有分表
            results.extend(execute_query(sql, order_id))
        return results

六、故障处理：那些年踩过的坑

6.1 死锁问题处理

-- 查看最近的死锁信息
SHOW ENGINE INNODB STATUSG

-- 查找当前的锁等待
SELECT 
    r.trx_id waiting_trx_id,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx_id,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query
FROM information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

-- 杀掉阻塞的事务
KILL 12345;  -- thread_id

预防死锁的最佳实践：

1. 保持事务简短

2. 按相同顺序访问表和行

3. 使用较低的隔离级别（如RC）

4. 为表添加合适的索引避免锁表

6.2 主从延迟问题

#!/bin/bash
# 监控主从延迟脚本

check_slave_lag() {
    lag=$(mysql -h$1 -e "SHOW SLAVE STATUSG" | grep "Seconds_Behind_Master" | awk '{print $2}')
    if [ "$lag" = "NULL" ]; then
        echo "Slave is not running on $1"
        # 发送告警
    elif [ "$lag" -gt 10 ]; then
        echo "Warning: Slave lag on $1 is ${lag} seconds"
        # 发送告警
    else
        echo "Slave $1 is healthy, lag: ${lag}s"
    fi
}

# 检查所有从库
for slave in slave1.db.com slave2.db.com; do
    check_slave_lag $slave
done

6.3 连接池爆满问题

-- 诊断连接问题
-- 查看当前连接数
SHOW STATUS LIKE 'Threads_connected';

-- 查看最大连接数设置
SHOW VARIABLES LIKE 'max_connections';

-- 查看连接来源分布
SELECT 
    user, host, count(*) as connections,
    GROUP_CONCAT(DISTINCT db) as databases
FROM information_schema.processlist
GROUP BY user, host
ORDER BY connections DESC;

-- 找出长时间Sleep的连接
SELECT * FROM information_schema.processlist 
WHERE command = 'Sleep' 
AND time > 300
ORDER BY time DESC;

七、性能优化工具箱

7.1 必备工具清单

1. percona-toolkit：MySQL DBA的瑞士军刀

2. MySQLTuner：一键诊断配置问题

3. sysbench：压力测试工具

4. mysql-sniffer：实时抓取SQL语句

5. Prometheus + Grafana：监控可视化

7.2 自动化优化脚本

#!/bin/bash
# auto_optimize.sh - MySQL自动优化脚本

echo "=== MySQL Performance Auto-Optimization ==="

# 1. 分析慢查询
echo "Analyzing slow queries..."
pt-query-digest /var/log/mysql/slow.log --limit=10 > /tmp/slow_analysis.txt

# 2. 检查表碎片
echo "Checking table fragmentation..."
mysql -e "
SELECT 
    table_schema, table_name, 
    ROUND(data_free/1024/1024, 2) as data_free_mb
FROM information_schema.tables
WHERE data_free > 100*1024*1024
ORDER BY data_free DESC;"

# 3. 分析索引使用情况
echo "Analyzing index usage..."
mysql -e "
SELECT 
    object_schema, object_name, index_name, 
    count_star as usage_count
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema NOT IN ('mysql', 'performance_schema')
AND index_name IS NOT NULL
ORDER BY count_star DESC
LIMIT 20;"

# 4. 生成优化建议
echo "Generating optimization recommendations..."
mysqltuner --outputfile /tmp/mysqltuner_report.txt

echo "Optimization report generated at /tmp/"

实战总结：优化是个系统工程

经过这些年的实战，我总结出MySQL优化的核心原则：

1. 监控先行：没有监控就没有优化。建立完善的监控体系是第一步。

2. 对症下药：不要盲目优化。先找到瓶颈，再针对性解决。

3. 小步快跑：每次只改一个参数，观察效果后再继续。避免"优化过度"。

4. 备份为王：任何优化操作前，先备份。我见过太多"优化变故障"的案例。

5. 持续学习：MySQL在不断进化，8.0的很多特性都值得研究。

写在最后

MySQL优化不是一蹴而就的，它需要持续的观察、分析和调整。希望这篇文章能给你一些启发。如果你在实际工作中遇到了有趣的优化案例，欢迎在评论区分享。

记住：最好的优化是不需要优化。在设计之初就考虑性能问题，比事后优化要轻松得多。

如果这篇文章对你有帮助，别忘了点赞收藏。我会持续分享更多运维实战经验，下期我们聊聊"Kubernetes故障排查的18般武艺"。

打开APP阅读更多精彩内容