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掉