数据库相关
-
MySQL的索引使用
默认会有主键索引。
索引分类：单值索引、复合索引、唯一索引
-
MySQL explain 分析
MySQL通过
explain关键字分析SQL的执行计划。（Oracle通过EXPLAIN PLAN FOR sql）ID SELECT_TYPE TABLE PARTITIONS TYPE POSSIBLE_KEYS KEY KEY_LEN REF ROWS FILTERED EXTRA - ID：执行顺序由上至下，ID值越大越先执行。
- SELECT_TYPE：查询的类型。
- TABLE：输出结果集的表。
- PARTITIONS：分区表命中的分区情况，非分区表为空。
- TYPE：重要指标之一，访问类型。性能由好->差的连接类型为：
system -> const -> eq_ref -> ref -> ref_or_null -> index_merge -> index_subquery -> range -> index -> all。 - POSSIBLE_KEYS：可能使用到的索引。
- KEY：实际使用到的索引。
- KEY_LEN：KEY的长度，越短越好。
- REF：表连接的匹配条件。const：常数等值查询；func：表达式或函数或内部隐式转换。
- ROWS：扫描行的数量。（估算）
- FILTERED：条件过滤后，对比总数的百分比。
- EXTRA：执行情况的说明和描述。
-
说说反模式设计
数据库范式能够使数据库表的设计更加规范，但会导致业务模型涉及的表过多，一次查询需要多次关联，导致性能变差。出于对性能的保护，提出了反模式设计。核心思想是：空间换时间，数据冗余避免表关联过多产生的问题。
-
说说分库与分表设计
一般表数据大于500万行或单表容量超过2GB。
分库分表策略（分片策略）：1、日期 2、Hash 3、范围 4、税率
数据库中间件：MyCat 、 ShadingJDBC
分库分表后查询逻辑：
- 携带分片字段：对具体表进行分页查询。
- 不携带分片字段：对每张表进行分页查询，然后通过中间件进行整合二次分页后返回给客户端。
-
分库与分表带来的分布式困境与应对之策
产生的问题含有：跨库JOIN问题、排序分页问题、分布式ID问题
跨库JOIN应对之策：
1）建立全局表，存放所有模块可能依赖的字段，但只能存不怎么修改的字段。
2）字段冗余设计，也就是反模式设计
排序分页应对之策：
1）增大PageSize
2）禁止跳页查询，只允许下一页
分布式ID应对之策：
1）UUID
2）数据库自增
3）号段模式
4）类似雪花算法
-
说说SQL优化之道
1）定位慢SQL
2）分析执行计划
3）增加索引或修改SQL
-
MySQL遇到的死锁问题
1、本人经历过的数据库连接数导致生产死锁的问题
正常逻辑为：A请求B数据->请求C数据->释放连接。
数据库连接数为8，恰逢8个请求占有了连接数，连接未释放；此时新进的请求需要连接，相互等待资源释放，却又因为B->C连接数满无法等到，导致死锁。
-
存储引擎MyISAM和InnoDB
MyISAM不支持事务。
由于多数系统都需要数据库的事务支持，MyISAM不支持事务，因此现有大部分都是InnoDB存储引擎。
-
数据库索引的原理
Mysql以B+树为数据结构，通过树结构存储索引的数据，并在叶子结点存储索引的值。
-
为什么要使用B树
查询效率高。
-
聚集索引与非聚集索引的区别
聚集索引：一个表只能有一个。占用空间较非聚集索引小。
-
limit 20000 加载很慢，如何处理
MySQL的性能低是因为数据库要去扫描N + M条记录，然后又要放弃之前N 条记录，开销很大。
1、缓存进行优化
2、延迟关联：先通过limit查找索引字段，再通过原表和索引字段关联获得需要的数据
-
选择合适的分布式主键方案
根据每个方案进行分析：
1）UUID
简单，长度过长，没有具体业务含义，不利于索引。
2）数据库自增
2.1 单节点：创建一个表，每次插入一条数据，根据返回的自增主键为分布式主键。单节点有宕机风险。
2.2 集群：不同集群的自增设置起始值和步长。后期扩容时，需要考虑冲突。
3）号段模式
一批号段的主键ID，用完再次申请。
4）类似雪花算法
64位的ID，各大厂商有自己的一些开源框架，自行查看。