MySQL高频面试题的灵魂拷问

码咖

The following article comes from 代码如诗 Author 朴瑞卿

计算机技术相关文章分享: 架构、中间件、源码解析、开发工具、运维等.

十个MySQL知识点(面试题), 查漏补缺, 共同学习, 欢迎交流.
文章地址: https://blog.piaoruiqing.com/2019/12/08/mysql-knowledge-point/

唯一索引比普通索引快吗, 为什么

唯一索引不一定比普通索引快, 还可能慢.

查询时, 在未使用limit 1的情况下, 在匹配到一条数据后, 唯一索引即返回, 普通索引会继续匹配下一条数据, 发现不匹配后返回. 如此看来唯一索引少了一次匹配, 但实际上这个消耗微乎其微.
更新时, 这个情况就比较复杂了. 普通索引将记录放到change buffer中语句就执行完毕了. 而对唯一索引而言, 它必须要校验唯一性, 因此, 必须将数据页读入内存确定没有冲突, 然后才能继续操作. 对于写多读少的情况, 普通索引利用change buffer有效减少了对磁盘的访问次数, 因此普通索引性能要高于唯一索引.

通过整库备份+binlog进行恢复. 前提是要有定期整库备份且保存了binlog日志.

第一范式: 属性不可再分.
第二范式: 在一范式的基础上, 要求数据库表中的每个实例或行必须可以被惟一地区分. 通常需要为表加上一个列, 以存储各个实例的惟一标识. 这个惟一属性列被称为主关键字或主键.
第三范式: 在二范式的基础上, 要求一个数据库表中不包含已在其它表中已包含的非主关键字信息. 所以第三范式具有如下特征：1). 每一列只有一个值. 2). 每一行都能区分. 3). 每一个表都不包含其他表已经包含的非主关键字信息.

数据量过大的情况下, limit offset分页会由于扫描数据太多而越往后查询越慢. 可以配合当前页最后一条ID进行查询, SELECT * FROM T WHERE id > #{ID} LIMIT #{LIMIT}. 当然, 这种情况下ID必须是有序的, 这也是有序ID的好处之一.

分库分表. 由于历史订单使用率并不高, 高频的可能只是近期订单, 因此, 将订单表按照时间进行拆分, 根据数据量的大小考虑按月分表或按年分表. 订单ID最好包含时间(如根据雪花算法生成), 此时既能根据订单ID直接获取到订单记录, 也能按照时间进行查询.

您点的每一个“在看”, 都是对作者的鼓励👇