前言：面试时，可能会遇到面试官，问有无数据库分库分表的经验。回想起博主的项目经历，的确有过，遂结合当时的情况，Mark一下。
答题思路
分两种情况：
1、实际项目中遇到过，简要说明一下，项目背景后，重点描述遇到的问题，以及分析排查的思路，中间遇到的曲折，最后采用数据库分库分表的方式解决了该问题。这样有理有据，推荐采用此种方式回答；
2、没遇到过，那么可以用之所以…是因为… 方式回答，说说之所以要进行数据库分库分表的操作，是因为…？解决该问题的技术手段有哪些？eg：之所以要进行数据库分库分表的操作，是因为关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限，导致性能差，常见的就是响应速度慢。一般采用数据切分的方式解决，数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分。回答到这里，如果面试官想要深入问你，那么就结合你掌握的知识进行相关的细节补充即可！
案例分享
以下为笔者的实际经历，仅供参考：
客户反馈的问题
用户访问移动端微信小程序，访问排行榜页面响应时间长达25s左右，严重影响用户体验。
分析思路
大体思路：分析客户线上环境的配置，准备相应的数据，监控日志，场景复现，锁定原因后，提供可优化的方案。
操作流程
要想完美复现，条件允许的情况下，硬件，软件，用户操作尽可能一致！！！
- 硬件方面：与客户的运维人员沟通后，对方提供相应配置等信息；
- 软件方面：与公司研发人员沟通后，了解系统架构，记录数据等信息；
- 用户操作：与客户或产品、测试沟通，确定相应行为；
测试环境准备好后，采用控制变量法，在测试环境的数据库中添加数据与线上环境数据库的数据一致后，大概率会情景复现。
通过查看log，找出访问排行榜页面时，查询的SQL，看SQL的执行计划，能否通过添加索引，替换join等方式，提高查询速度。（最终通过增加分区，提升了查询速度）
实验结果
分区前，在160W级数据量的情况下，执行查询语句，耗时分别为19.4s，18.8s，18.6s,平均耗时为：18.9s。
分区后，在160W级数据量的情况下，执行查询语句，耗时分别为3.94s，2.28s，2.25s,平均耗时为：2.82s。
总结
通过分区表的方式，在160w数据量场景下，查询速度提升了6.70倍；
收获分区表的相关知识。
- 分区表的创建方式分类
- 分区表分区的字段，必须为主键
可能遇到的问题
报错：Table has no partition for value XXX
含义：对已存在的未分区的表进行分区，原因是分区没有包含表中所有数据
解决方案：增加分区区间，确保对所有数据进行了分区
报错：Duplicate entry ‘4398-OPEN’ for key ‘PRIMARY’
含义：主键是在同一张表中必须唯一的
解决方案：添加主键定义
报错：A PRIMARY KEY must include all columns in the table’s partitioning function
含义：分区的字段必须是要包含在主键当中。这时候分区的字段要么是主键，要么把分区字段加入到主键中，从而形成复合主键
解决方案：将字段设置为主键
报错：value must be strictly increasing for each partition
含义：新增的值比原来定义的分区小
解决方案：字段的值按大小顺序依次排列
参考链接
Mysql官方文档
Mysql分区表创建
Mysql数据库分区字符串匹配
数据库分库分表，何时分？怎样分？
|