没有合适的资源?快使用搜索试试~ 我知道了~
100道MySQL面试题及答案
资源推荐
资源详情
资源评论
1. MySQL 索引使用有哪些注意事项呢?
可以从三个维度回答这个问题:索引哪些情况会失效,索引不适合哪些场景,索引规则
索引哪些情况会失效
查询条件包含 or,可能导致索引失效
如何字段类型是字符串,where 时一定用引号括起来,否则索引失效
like 通配符可能导致索引失效。
联合索引,查询时的条件列不是联合索引中的第一个列,索引失效。
在索引列上使用 mysql 的内置函数,索引失效。
对索引列运算(如,+、-、*、/),索引失效。
索引字段上使用(!= 或者 < >,not in)时,可能会导致索引失效。
索引字段上使用 is null, is not null,可能导致索引失效。
左连接查询或者右连接查询查询关联的字段编码格式不一样,可能导致索引失效。
mysql 估计使用全表扫描要比使用索引快,则不使用索引。
后端程序员必备:索引失效的十大杂症
索引不适合哪些场景
数据量少的不适合加索引
更新比较频繁的也不适合加索引
区分度低的字段不适合加索引(如性别)
索引的一些潜规则
覆盖索引
回表
索引数据结构(B+树)
最左前缀原则
索引下推
2. MySQL 遇到过死锁问题吗,你是如何解决的?
我排查死锁的一般步骤是酱紫的:
查看死锁日志 show engine innodb status;
找出死锁 Sql
分析 sql 加锁情况
模拟死锁案发
分析死锁日志
分析死锁结果
可以看我这两篇文章哈:
手把手教你分析 Mysql 死锁问题
Mysql 死锁如何排查:insert on duplicate 死锁一次排查分析过程
3. 日常工作中你是怎么优化 SQL 的?
可以从这几个维度回答这个问题:
加索引
避免返回不必要的数据
适当分批量进行
优化 sql 结构
分库分表
读写分离
可以看我这篇文章哈:
后端程序员必备:书写高质量 SQL 的 30 条建议
4. 说说分库与分表的设计
分库分表方案,分库分表中间件,分库分表可能遇到的问题
分库分表方案:
水平分库:以字段为依据,按照一定策略(hash、range 等),将一个库中的数据拆分到多个
库中。
水平分表:以字段为依据,按照一定策略(hash、range 等),将一个表中的数据拆分到多个
表中。
垂直分库:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。
垂直分表:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)
中。
常用的分库分表中间件:
sharding-jdbc(当当)
Mycat
TDDL(淘宝)
Oceanus(58 同城数据库中间件)
vitess(谷歌开发的数据库中间件)
Atlas(Qihoo 360)
分库分表可能遇到的问题
事务问题:需要用分布式事务啦
跨节点 Join 的问题:解决这一问题可以分两次查询实现
跨节点的 count,order by,group by 以及聚合函数问题:分别在各个节点上得到结果后在应用
程序端进行合并。
数据迁移,容量规划,扩容等问题
ID 问题:数据库被切分后,不能再依赖数据库自身的主键生成机制啦,最简单可以考虑 UUID
跨分片的排序分页问题(后台加大 pagesize 处理?)
个人觉得网上这两篇文章不错,小伙伴们可以去看一下哈:
MySQL 数据库之互联网常用分库分表方案
分库分表需要考虑的问题及方案
5. InnoDB 与 MyISAM 的区别
InnoDB 支持事务,MyISAM 不支持事务
InnoDB 支持外键,MyISAM 不支持外键
InnoDB 支持 MVCC(多版本并发控制),MyISAM 不支持
select count(*) from table 时,MyISAM 更快,因为它有一个变量保存了整个表的总行数,可
以直接读取,InnoDB 就需要全表扫描。
Innodb 不支持全文索引,而 MyISAM 支持全文索引(5.7 以后的 InnoDB 也支持全文索引)
InnoDB 支持表、行级锁,而 MyISAM 支持表级锁。
InnoDB 表必须有主键,而 MyISAM 可以没有主键
Innodb 表需要更多的内存和存储,而 MyISAM 可被压缩,存储空间较小,。
Innodb 按主键大小有序插入,MyISAM 记录插入顺序是,按记录插入顺序保存。
InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全,与 MyISAM 比 InnoDB
写的效率差一些,并且会占用更多的磁盘空间以保留数据和索引
6. 数据库索引的原理,为什么要用 B+树,为什么不用二叉树?
可以从几个维度去看这个问题,查询是否够快,效率是否稳定,存储数据多少,以及查找磁
盘次数,为什么不是二叉树,为什么不是平衡二叉树,为什么不是 B 树,而偏偏是 B+树呢?
为什么不是一般二叉树?
如果二叉树特殊化为一个链表,相当于全表扫描。平衡二叉树相比于二叉查找树来说,查找
效率更稳定,总体的查找速度也更快。
为什么不是平衡二叉树呢?
我们知道,在内存比在磁盘的数据,查询效率快得多。如果树这种数据结构作为索引,那我
们每查找一次数据就需要从磁盘中读取一个节点,也就是我们说的一个磁盘块,但是平衡二
叉树可是每个节点只存储一个键值和数据的,如果是 B 树,可以存储更多的节点数据,树的
高度也会降低,因此读取磁盘的次数就降下来啦,查询效率就快啦。
那为什么不是 B 树而是 B+树呢?
1)B+树非叶子节点上是不存储数据的,仅存储键值,而 B 树节点中不仅存储键值,也会存
储数据。innodb 中页的默认大小是 16KB,如果不存储数据,那么就会存储更多的键值,相
应的树的阶数(节点的子节点树)就会更大,树就会更矮更胖,如此一来我们查找数据进行
磁盘的 IO 次数有会再次减少,数据查询的效率也会更快。
2)B+树索引的所有数据均存储在叶子节点,而且数据是按照顺序排列的,链表连着的。那
么 B+树使得范围查找,排序查找,分组查找以及去重查找变得异常简单。
可以看这篇文章哈:
再有人问你为什么 MySQL 用 B+树做索引,就把这篇文章发给她
7. 聚集索引与非聚集索引的区别
一个表中只能拥有一个聚集索引,而非聚集索引一个表可以存在多个。
聚集索引,索引中键值的逻辑顺序决定了表中相应行的物理顺序;非聚集索引,索引中索引
的逻辑顺序与磁盘上行的物理存储顺序不同。
索引是通过二叉树的数据结构来描述的,我们可以这么理解聚簇索引:索引的叶节点就是数
据节点。而非聚簇索引的叶节点仍然是索引节点,只不过有一个指针指向对应的数据块。
聚集索引:物理存储按照索引排序;非聚集索引:物理存储不按照索引排序;
何时使用聚集索引或非聚集索引?
8. limit 1000000 加载很慢的话,你是怎么解决的呢?
方案一:如果 id 是连续的,可以这样,返回上次查询的最大记录(偏移量),再往下 limit
select id,name from employee where id>1000000 limit 10.
方案二:在业务允许的情况下限制页数:
建议跟业务讨论,有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。
方案三:order by + 索引(id 为索引)
select id,name from employee order by id limit 1000000,10
方案四:利用延迟关联或者子查询优化超多分页场景。(先快速定位需要获取的 id 段,然后
剩余34页未读,继续阅读
资源评论
烈日下的奔跑
- 粉丝: 1073
- 资源: 232
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功