***************************************目录*************************************************
- 3.1. DP数据库部署方案如何？
- 3.2. DP数据库配置/最大连接数/TPS/QPS？
- 3.3. 分库分表如何设计，细节/难点/多维度分库分表？
- 3.4. 数据库高可用、高性能方案？
- 3.5. 主从延迟问题，如何查看，有米有监控和告警？
- 3.6. 点评mysql是单实例还是多实例部署，why？
- 3.7. 数据库连接开销有哪些,应用设置最大连接怎么评估（todo）？
- 3.8. 数据库行锁的等待超时时间是多少，可不可以自定义（todo）？
- 3.9. 数据恢复功能是否开放？
- 3.10. 实时慢sql在哪里可以查？
- 3.11. 大批量删除数据后，需要重建索引么，消除高水位线？
- 3.12. 丽人数据库集群情况？
- 3.13. autoCommit问题？
- 3.14. innoDB buffer pool问题？
- 3.15. 全量表快照表区别？
- 3.16. 开发常见sql问题汇总（持续收集）
***************************************概要*************************************************
*************************************问题解答***********************************************
- 15年之前采用的MMM架构，15年之后采用MHA+zebra，详情见： /Users/zhoudengyun/Documents/学习资料/db/蔡金龙-美团点评数据库高可用架构的演进与设想;
线上部署方案是单Master单Slave 目前丽人相关数据库有两个集群：beauty集群(41个库)、beautycomesticzone集群(2个库)
目前线上是单实例多数据库(Schema)，所有数据库共享物理资源、链接数
- mysql服务器 ：120G内存，os 20，mysql instance 100，CPU 48核的；
- 最大连接数：2W (所有数据库共享)，TPS安全线：3K~5K, QPS:十几W（主键简单查询）
- 参考：
大众点评支付分库分表：https://tech.meituan.com/dianping_order_db_sharding.html
58同城分库分表：https://mp.weixin.qq.com/s/kOTz5XAeAcUI2gzKl7AEHw 多维度的化，通常采用冗余方式，eg:用户维度hash一次，订单维度再hash一次以空间换时间；
还有一种方式即为：维度映射查询，eg:用户维度hash之后，希望根据商户维度，可以在redis保存userId→shopID映射
基因法 ，详细见
- 参考：/Users/zhoudengyun/Documents/学习资料/db/蔡金龙-美团点评数据库高可用架构的演进与设想;
产生的原因：
- 执行了一个耗时较久的语句，比如暴力的update、delete、insert了过多的记录，可以通过zabbix或者binlog确认。
- Mater上在较短的时间执行了大量的更新操作（update、delete、insert），Slave来不及执行，导致，可以通过查看zabbix监控来确定原因。
- Slave上IO恶化（大量的读取操作等），导致Slave上Replay binlog比较缓慢。
参考：https://wiki.sankuai.com/pages/viewpage.action?pageId=77480628
从延迟告警默认阈值是180s，业务方可以自己调整，关注对应数据集群后能收到告警信息。
首先目前点评是单实例，没有采用多实例，因为测试下来，单实例性能较好而且便于管理；
目前单实例是部署的有多个数据库，多个数据库共享资源，所有会出现一个库会拖垮另一个库的情况；
- 目前数据库支持的最大连接数是2W,一般应用配置连接池：30~50即可； 详情：todo
- todo
3.11. 大批量删除数据后，需要重建索引么，消除高水位线？
mysql没有高水位线概念，这个是oracle概念；
mysql物理删除数据，内存空间不会释放，只是被标记为free，后续重利用；
- 由CASE引发的一些思考，buffer pool命中率下降，导致慢查询飙升；TODO
*************************************开发常见sql问题汇总*******************************************
- 这个是mysql5.6的bug,后续点评mysql会升级到5.7，目前在陆续升级（mysql order by和limit使用遭遇的困惑）
order by limit 造成优化器选择索引错误分析见：
https://yq.aliyun.com/articles/51065
王广友-MySQL order by limit优化器bug数据库分页，偏移量过大导致bug，case
数据库死锁问题汇总，关联阅读：
pt-online-schema-change执行期间报deadlock与lock wait timeoutMDL问题汇总：
关于Waiting for table metadata lock问题的说明
Mysql Metadata Lock
https://wiki.sankuai.com/pages/viewpage.action?pageId=451439517
MySql死锁CASE
- 介绍 简单的理解就是执行 delete from `order` where customer_id = 3。这里在order表里面没有customer_id=3 的记录。但是又由于customer_id存在一个索引，mysql根据索引进行搜索，索引的key是(1,2,6)，3不在这些key里面而是位于(2,6)之间的gap（间隙）中。Mysql对于(2,6)这个间隙加的锁就叫做Gap锁。
- 特点 间隙锁只会阻塞insert操作,对于delete和update操作是不会阻塞的，由于锁住的是空隙，所以对于delete和update操作相当于在空数据上操作，没有意义。
- 解决 在delete的时候，不让事务获取到Gap锁。比如，在执行delete from `order` where customer_id = 3 ;之前， 我们可以先用主键查询看数据是否存在，存在再用主键删除，即可解决上述的死锁问题。
- 关联CASE CASE
- 参考阅读 ref1