Mysql优化

1.架构方面：

读写分离（数据量比较大）

分库分表（数据量大，无法用索引来满足，并且并发量太大，）

缓存（经常要查询的数据，每个表比较常用的字段）

主从复制

2.硬件

内存大于16G（因为里面有bufferpool占了75%，因为磁盘要加载到内存，如果太小的话要持续的刷脏）

cpu的大小 8核16g的

mysql的版本

mysql的连接数，连接池，有多少个连接数是最优的么？这个要看cpu的核心数*2+1（如果固态硬盘），不能说是100个连接数 然后cpu是8核的，那肯定是不行的

硬盘（固态硬盘）

3.sql优化

1. select * 全文扫描，这个肯定是不行的，性能太低了，如果数据量在百万级别的，会超级慢

2.在写业务代码的时候，团队开发，需要查询同一个表数据，我可以查完之后，当参数给下游，这样这条业务就减少数据库io

3.避免深度分页，比如说要查询100w条后面的20条，select FROM XX where id>100W LIMIT 20但是这个能实现的前提是主键必须的自增的，如果不是自增的，那就让前端把末尾的数据的主键id带过来就好了

4.日期类型的选择 datetime8字节、timestamp4字节、date3字节

5.对于一些状态字段，用tinyint，占的字节少，只有1字节

6.对于已经知道字符串长度的字段，可以用char，就没必要用varchar

7.根据阿里云查看慢sql日志，拿到慢sql，通过explain关键字分析，观察type里面的类型

system -----const特例

const -----代表走了主键索引、唯一索引

eq_ref---关联表的时候，如果关联字段是主键索引或者唯一索引

ref-----代表走了普通索引

range

index----代表走的是索引覆盖、索引下推

all-----代表全表扫描

越往后越慢，主要是往前面调这个type来调，一点一点向前调

4.索引

1.最左匹配原则

2.索引覆盖

3.索引下推

4.尽量使用主键自增，避免叶分裂

5.排序和分组的时候要用到索引

6.LIKE查询的时候%放在左边索引失效

7.范围查询的时候条件放到最后

8.or两边 如果有一个字段没有建立索引，会导致全表扫描

9.update where后面没有索引，会从行锁升级成表锁

如果发生表锁，另一个事务一直在卡着，但是实际上我们不知道到底哪里出了问题，要怎么排查？

select*FROM information_schema.innodb_trx 

可以查看一下 正在运行的事物，什么时候开启的，锁了多少行数据

如果一直在阻塞状态

kill+事物id

show processlist 命令可以看见哪些线程一直处于阻塞状态，time时间长的话就该注意了，可以kill掉