数据库如何调优

1、是否选对了索引

可以根据explain 计划

对于 order by groupby的要根据索引排序，不然会引起磁盘排序

对于经常查询的字段 要加索引，比如根据order_id 查订单状态，可以加 orderId 和 status 联合索引，为什么加上status，因为根据索引的特点，叶子结点存的是 索引字段，直接从叶子结点拿status就行了，不必再回表查找，也是充分利用覆盖索引的情况

2、是否用到了覆盖索引

比如分页的时候可以利用覆盖索引，子查询实现

优化select * from

3、是否选对了隔离级别

4、避免行所升级为表锁，如果查询 条件不加索引，就会升级为表锁

5、拒绝大事务

如果事务过长，一直不释放锁，会导致其他事务一直等待，会导致连接池被打满

可以将多个主流程拆分成多个子流程，异步去实现子模块，比如用消息队列，线程池异步

猫眼票务的异步是通过自己实现的一个框架  数据库落地加线程池异步实现的

为什么不用mafka的异步呢，虽然makfa已经比较稳定，但是万一mafka挂掉，获取消息丢失，没法去定位问题

我们把每个异步任务 设计成一个processor，并在数据库存一个taskid，和 订单id 和 groupId

然后线程池获取任务，并异步执行

对于失败的异步，存在重试，如果重试一定次数会失败

会定时的去处理失败的任务，并去做补偿操作

 

4、是否需要分库分表

   前期设计的时候，先不分库分表，但是要给以后分表留下口子

美团是严格不让join查询的，而是需要多个简单查询去实现

分库后复杂查询怎么办，再下单时 可以异步当缓存和es里一份，用es查询

 

对于后台系统的分页查询，如分页查询订单状态，创建时间。订单创建的时候 异步存es，或大数据哪里

 

冷热数据

比如购物车列表，一个月之内的都算作是热数据，我们需要提前存入redis缓存中

 

对于库存的设计

可以使用状态机和分布式锁 解决 库存超卖和 一个人下多次单情况

 

 

 

 

作为一个java开发，我觉得很有必要去好好了解下数据库

当然了解不够深入，也不影响开发，但是绝对不能写出最优的代码

我自己花过很长时间去学习过 事务特性

原子性

那么在引擎层是如何实现的？

那就要学习undolog 吧，学习了undo log 就了解了 mvcc

 

一致性

 

持久性

意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失

那么就涉及到了学习 redo log

那么redo log是如何实现的呢，发现得要了解 innodb引擎了，就涉及到了 inno db buffer了

那么redo log是绝对的不丢吗，那就涉及到了innodb_flush_log_at_trx_commit 这个参数了

那么数据库调优的时候是不是可以在这方面考虑呢，比如innodb buffer的size长度设置的是否合理呢

 

 

那么隔离级别了

读未提交

为何为有读未提交，无非就是 insert的时候，放到buffer里的数据还没持久到磁盘就被另一个事务读到了，这就是脏读的问题了

不可重复度

对相同字段的多次读取结果一致（不可以重复度），不发生脏读，可导致幻读。 

那就是简称rc了，那么rc是如何实现的？

那就要学习事务版本号了，那为什么可导致幻读呢，那他的加锁机制又是什么呢，跟rr有何区别？

 

可重复读

那么又是如何实现的呢，为何可避免幻读呢

那就是加锁了，主键加 记录锁，唯一索引 会加记录锁，而且主键也会加个记录锁

对于普通索引，就是加next key 或gap锁了

 

不了解内部原理的同学估计还任务一个select查询会加锁，但是了解了远离后，才发现他是快照读

update的时候是当前读

如果了解了原理，就会好好写代码，会考虑多方面性能问题了

 

当去了解mysq加锁原理的时候，就会明白为什么 会有死锁的情况了，next key锁很有可能会导致死锁情况

 

那么死锁如何避免呢

update 和 delete的where条件不要是一个没加锁的，或者是普通索引，最好是主键

了解了锁就知道为什么了

所以我写代码的时候，对于update 和 delete的where条件，条件都是id，如果看到其他同事有其他字段的情况，我会提醒他去优化，我会耐心跟他讲解原理，养成好习惯比什么都重要

 

 

如果真的去深入理解的时候，发现要学习的东西太多，所以学习不仅仅是 学习表面，还需要多去深入源码好好地读一读吧

 

去年的时候，我读过jdk的源码，AQS还给团队做过分享，读了以后才发现源码的精髓，如果让自己去设计一个分布式锁，顿时有了思路，如果设计一个可重入的分布式锁，如何设计一个可等待的分布式锁呢，我顿时有了答案

 

有段时间我自己实在觉得索引好抽象，我就拿起笔，把每种索引创建过程自己用图画了一遍

顿时就理解了好多数据所说的，如果一直读别人的文章，文字是从别人的认知里总结出的东西，每个人的认知还不一样，我们不一定能真正的读懂他人的认知，那么就要自己去亲自尝试去读源码的东西，才会真正的理解精髓所在

数据库很基础，是需要多多去学习的，基础也是需要慢慢的积累和沉淀的，这就是为什么很多公司高薪聘用一个资深和专家了

因为一个基础导致的事故可是 损失的不止是钱

 

微信号 liuSIRCOMEon欢迎交流