MySQL进阶知识点(八)---- SQL优化

一、 插入数据优化

当需要插入大量数据时,普通的单条INSERT语句效率极低。

优化方案:

  1. 批量插入

    sql 复制代码
    -- 不推荐:多次网络I/O和事务开销
    INSERT INTO table VALUES (1, 'a');
    INSERT INTO table VALUES (2, 'b');
    
    -- 推荐:一次插入多条数据
    INSERT INTO table VALUES (1, 'a'), (2, 'b'), (3, 'c');
  2. 手动提交事务

    sql 复制代码
    -- 避免每条INSERT都自动提交事务
    START TRANSACTION;
    INSERT INTO table VALUES (1, 'a');
    INSERT INTO table VALUES (2, 'b');
    COMMIT;
  3. 主键顺序插入

    按主键的顺序插入数据,性能高于乱序插入。

  4. 使用LOAD指令

    对于海量数据插入,可以使用MySQL的LOAD命令从文件加载。

    sql 复制代码
    -- 从本地文件加载数据
    LOAD DATA LOCAL INFILE '/path/to/file.csv' 
    INTO TABLE table_name 
    FIELDS TERMINATED BY ',' 
    LINES TERMINATED BY '\n';

二、 主键优化

  1. InnoDB的数据组织方式

    • InnoDB使用B+Tree索引组织数据

    • 所有数据都存储在聚簇索引的叶子节点

  2. 页分裂与页合并

    • 页分裂:当页已满,新插入的数据会导致页分裂,影响性能

    • 页合并:当页中数据删除达到阈值(MERGE_THRESHOLD,默认50%),InnoDB会寻找相邻页合并

  3. 主键设计原则

    • 尽量短:二级索引叶子节点存储主键,主键过长会占用更多空间

    • 顺序插入:使用AUTO_INCREMENT或雪花算法等,避免随机主键

    • 避免频繁更新:主键更新会导致二级索引同步更新

三、 ORDER BY优化

  1. Using filesort的情况

    • 通过磁盘文件或内存进行排序,效率较低

    • 在EXPLAIN的Extra字段中显示Using filesort

  2. Using index的情况

    • 通过索引直接完成排序,效率高

    • 在EXPLAIN的Extra字段中显示Using index

  3. 优化方案:

    • 为ORDER BY的字段建立合适的索引

    • 遵循最左前缀法则

    • 多字段排序时,保持ORDER BY顺序与索引顺序一致

    • 避免SELECT *,减少回表操作

示例:

sql 复制代码
-- 索引: (age, salary)
-- 有效:使用索引排序
EXPLAIN SELECT id FROM employees ORDER BY age, salary;

-- 无效:出现Using filesort
EXPLAIN SELECT id FROM employees ORDER BY salary, age;

四、 GROUP BY优化

  1. Using temporary的情况

    • 使用临时表进行分组,效率较低

    • 在EXPLAIN的Extra字段中显示Using temporary

  2. 优化方案:

    • 为GROUP BY字段建立索引

    • 在GROUP BY后使用ORDER BY NULL取消排序(如不需要排序结果)

    • 遵循最左前缀法则

示例:

sql 复制代码
-- 索引: (dept_id)
-- 优化前:可能使用临时表
EXPLAIN SELECT dept_id, COUNT(*) FROM employees GROUP BY dept_id;

-- 优化后:使用索引,取消排序
EXPLAIN SELECT dept_id, COUNT(*) FROM employees GROUP BY dept_id ORDER BY NULL;

五、 LIMIT优化

在大数据量下,LIMIT分页的深分页问题:

sql 复制代码
-- 效率低:OFFSET越大越慢
SELECT * FROM table LIMIT 1000000, 10;

优化方案:

  1. 覆盖索引 + 子查询

    sql 复制代码
    SELECT * FROM table t
    JOIN (SELECT id FROM table ORDER BY id LIMIT 1000000, 10) tmp
    ON t.id = tmp.id;
  2. 基于上次位置的查询(游标分页)

    sql 复制代码
    -- 传统分页
    SELECT * FROM table ORDER BY id LIMIT 20;
    
    -- 下一页(记录上次的最大id)
    SELECT * FROM table WHERE id > 上次的最大id ORDER BY id LIMIT 20;

六、 COUNT优化

  1. COUNT的几种用法

    • COUNT(主键):InnoDB遍历整表,把主键值取出,按行累加

    • COUNT(字段):统计该字段不为NULL的数量

    • COUNT(1):InnoDB遍历整表,但不取值,按行累加

    • COUNT(*):MySQL做了优化,不取值,按行累加

  2. 效率对比
    COUNT(*)COUNT(1) > COUNT(主键) > COUNT(字段)

  3. 优化方案:

    • 使用COUNT(*),MySQL会自行优化

    • 维护计数表,实时更新总数

    • 使用Redis等外部缓存记录总数

七、 UPDATE优化

核心原则: 避免表锁,使用行锁。

  1. InnoDB的行锁

    • 基于索引加行锁

    • 不基于索引加表锁

  2. 优化方案:

    sql 复制代码
    -- 索引: (id)
    -- 高效:使用行锁
    UPDATE table SET name = 'new' WHERE id = 1;
    
    -- 危险:无索引,使用表锁,阻塞其他操作
    UPDATE table SET name = 'new' WHERE name = 'old';
  3. 最佳实践

    • 确保WHERE条件使用索引

    • 避免在事务中执行大量UPDATE

    • 分批更新大数据量

优化总结表格

优化场景 核心问题 优化方案
插入数据 单条插入效率低 批量插入、手动事务、LOAD DATA
主键设计 页分裂、空间占用 短主键、顺序插入、避免更新
ORDER BY Using filesort 创建合适索引、遵循最左前缀
GROUP BY Using temporary 创建索引、ORDER BY NULL取消排序
LIMIT 深分页性能差 覆盖索引+子查询、游标分页
COUNT 全表扫描效率低 使用COUNT(*)、维护计数表
UPDATE 表锁阻塞 WHERE条件必须使用索引

通用优化建议

  1. 善用EXPLAIN:分析SQL执行计划是优化的第一步

  2. 索引是双刃剑:合理创建,避免过多

  3. **避免SELECT ***:只查询需要的字段

  4. 大数据量操作:分批处理,避免大事务

相关推荐
zz-zjx18 小时前
MySQL 开源主从复制实战指南(SRE 可靠性优先版)
数据库·mysql·开源
Microsoft Word1 天前
向量数据库与RAG
数据库·人工智能·向量数据库·rag
艾德金的溪1 天前
redis-7.4.6部署安装
前端·数据库·redis·缓存
小光学长1 天前
基于Vue的2025年哈尔滨亚冬会志愿者管理系统5zqg6m36(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。
前端·数据库·vue.js
我的offer在哪里1 天前
Redis
数据库·redis·缓存
点灯小铭1 天前
基于单片机的多模式自动洗衣机设计与实现
数据库·单片机·嵌入式硬件·毕业设计·课程设计
潜心编码1 天前
基于python的仓库管理系统
数据库
herinspace1 天前
如何设置电脑分辨率和显示缩放
服务器·数据库·智能手机·电脑
biubiubiu07061 天前
Ubuntu中定时任务测试
数据库·postgresql