Mysql优化在工作中的经验总结
温馨提示：因工作繁忙，该文章内容目前还处于待更新的未完成状态，但是你仍然可以查看文章中已有内容，找寻你所需要信息。若你有相关建议可在评论区留言与我进行讨论，谢谢！
随心而论：
无论作为研发或者是运维人员，对于数据库的优化接触最多的应该是对于索引的优化。而像分库分表，引入缓存等常规操作，个人认为更多的是架构设计层面的拓展。在本文中就不对这类知识进行展开了。
- 对于百万级别的表基本都可以通过索引优化解决性能问题，如果解决不了那么你需要加大一下MySQL的内存空间，让合理优化后的索引能够顺利加载进内存后。基本也可以解决！
- 你可以选择相信mysql的性能，我们尝试过百万级数据的表，只利用2C4G的性能规格依旧可以运行良好。
Explain解释内容说明：
索引基本知识：
是否使用索引的几种情况:
| 使用索引 | 不使用索引 | 自身会使用索引 |
| union,in,= | or(新版本可以使用到),like "%abc",!=,<>,not in,not exists,not like,is null,is not null | <,<=,>,>=,between,like "abc%" |
| 其他索引失效情况 | ||
| 1、索引列进行了函数计算，索引失效。 2、索引列进行了强制类型转换或者比较，索引失效 |
||
优化经验分享：
1、当你的查询条件是时间，而主键是自增模式的情况下。如果对ID做倒序排序存在慢查询，那么你可以试试改为直接使用时间做排序条件。
#原SQL select * from order where order_date < "2021-09-06" order by id desc; #尝试优化为 select * from order where order_date < "2021-09-06" order by order_date desc;
实战案例演示：
一些Mysql的命令：
A、binlog日志解析SQL语句
mysqlbinlog --no-defaults --base64-output=decode-rows -v
B、批量killmysql线程
SELECT concat(‘KILL ‘,id,’;’) FROM information_schema.processlist WHERE user=‘root’;
C、查看Mysql的锁信息
行锁：show engine innodb status
元数据锁: select * from `performance_schema`.metadata_locks
D、查看数据库的安装路径和数据存储路径
select * from `performance_schema`.global_variables where variable_name = "basedir"
select * from `performance_schema`.global_variables where variable_name = "datadir"
本文系作者 @Mr.Lee 原创发布在 维简网。未经许可，禁止转载。
