我把面试问烂了的⭐MySQL面试题⭐总结了一下（带答案，万字总结，精心打磨，建议收藏） |
您所在的位置：网站首页 › 新闻韩国越南日本为何要恢复汉字 › 我把面试问烂了的⭐MySQL面试题⭐总结了一下（带答案，万字总结，精心打磨，建议收藏） |
我把面试问烂了的⭐MySQL面试题⭐总结了一下（带答案，万字总结，精心打磨，建议收藏）
|
💂 个人主页: Java程序鱼 💬 如果文章对你有帮助，欢迎关注、点赞、收藏(一键三连)和订阅专栏 👤 微信号：hzy1014211086，想加入技术交流群的小伙伴可以加我好友，群里会分享学习资料、学习方法 序号内容链接地址1Java基础知识面试题https://blog.csdn.net/qq_35620342/article/details/1196364362Java集合容器面试题https://blog.csdn.net/qq_35620342/article/details/1199472543Java并发编程面试题https://blog.csdn.net/qq_35620342/article/details/1199772244Java异常面试题https://blog.csdn.net/qq_35620342/article/details/1199770515JVM面试题https://blog.csdn.net/qq_35620342/article/details/1199489896Java Web面试题https://blog.csdn.net/qq_35620342/article/details/1196421147Spring面试题https://blog.csdn.net/qq_35620342/article/details/1199565128Spring MVC面试题https://blog.csdn.net/qq_35620342/article/details/1199655609Spring Boot面试题https://blog.csdn.net/qq_35620342/article/details/12033371710MyBatis面试题https://blog.csdn.net/qq_35620342/article/details/11995654111Spring Cloud面试题待分享12Redis面试题https://blog.csdn.net/qq_35620342/article/details/11957502013MySQL数据库面试题https://blog.csdn.net/qq_35620342/article/details/11993088714RabbitMQ面试题待分享15Dubbo面试题待分享16Linux面试题待分享17Tomcat面试题待分享18ZooKeeper面试题待分享19Netty面试题待分享20数据结构与算法面试题待分享 文章目录 1. MySQL 索引使用有哪些注意事项呢？索引哪些情况会失效索引不适合哪些场景 2. MySQL 遇到过死锁问题吗，你是如何解决的？3. 日常工作中你是怎么优化SQL的？4. 分库分表的设计分库分表方案常用的分库分表中间件分库分表可能遇到的问题 5. InnoDB与MyISAM的区别6. 数据库索引的原理，为什么要用 B+树，为什么不用二叉树？为什么不是一般二叉树？为什么不是平衡二叉树呢？那为什么不是B树而是B+树呢？ 7. 聚集索引与非聚集索引的区别何时使用聚集索引或非聚集索引？ 8. limit 1000000 加载很慢的话，你是怎么解决的呢？9. 如何选择合适的分布式主键方案呢？10. 事务的隔离级别有哪些？MySQL的默认隔离级别是什么？读未提交(Read Uncommitted)串行化(Serializable)可重复读(Repeated Read, RR) 这是InnoDB默认的隔离级别，在RR下：读提交(Read Committed, RC) 这是互联网最常用的隔离级别，在RC下： 11. 在高并发情况下，如何做到安全的修改同一行数据？使用悲观锁使用乐观锁 12. 数据库的乐观锁和悲观锁悲观锁乐观锁 13. SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义？14. select for update有什么含义，会锁表还是锁行还是其他？15. MySQL事务得四大特性以及实现原理事务ACID特性的实现思想 16. 如果某个表有近千万数据，CRUD比较慢，如何优化？分库分表索引优化 17. 如何写sql能够有效的使用到复合索引？18. mysql中in 和exists的区别19. 数据库自增主键可能遇到什么问题？20. MVCC底层原理21. 数据库中间件了解过吗，sharding jdbc，mycat？22. MySQL的主从延迟，你怎么解决？主从复制分了五个步骤进行：主从同步延迟的原因主从同步延迟的解决办法 23. 说一下大表查询的优化方案24. 什么是数据库连接池?为什么需要数据库连接池呢?应用程序和数据库建立连接的过程数据库连接池好处 25. 一条SQL语句在MySQL中如何执行的？MySQL逻辑架构图连接器查询缓存分析器优化器执行器 26. InnoDB引擎中的索引策略，了解过吗？独立的列前缀索引和索引选择性多列索引选择合适的索引列顺序聚簇索引列的离散性 27. 数据库存储日期格式时，如何考虑时区转换问题？28. 一条sql执行过长的时间，你如何优化，从哪些方面入手？29. Blob和text有什么区别？30. MySQL里记录货币用什么字段类型比较好？31. InnoDB有哪几种锁？共享/排它锁(Shared and Exclusive Locks)意向锁(Intention Locks)记录锁(Record Locks)间隙锁(Gap Locks)临键锁(Next-key Locks)插入意向锁(Insert Intention Locks)自增锁(Auto-inc Locks) 32. Hash索引和B+树区别是什么？你在设计索引是怎么抉择的？33. mysql 的内连接、左连接、右连接有什么区别？34. 什么是内连接、外连接、交叉连接、笛卡尔积呢？35. 说一下数据库的三大范式36. mysql有关权限的表有哪几个呢？主从复制binlog格式有哪几种？有什么区别？ 38. Mysql主从复制方式？有什么区别？39. InnoDB内存结构包含四大核心组件40. 索引有哪些优缺点？优点缺点 41. 索引有哪几种类型？42. 创建索引的三种方式在执行CREATE TABLE时创建索引使用ALTER TABLE命令添加索引使用CREATE INDEX命令创建 43. 百万级别或以上的数据，你是如何删除的？44. 覆盖索引、回表等这些，了解过吗？45. B+树在满足聚簇索引和覆盖索引的时候不需要回表查询数据？46. 何时使用聚簇索引与非聚簇索引47. 非聚簇索引一定会回表查询吗？48. 组合索引是什么？为什么需要注意组合索引中的顺序？49. 什么是死锁？怎么解决？50. 你是如何监控你们的数据库的？你们的慢日志都是怎么查询的？MySQL技术体系思维导图 1. MySQL 索引使用有哪些注意事项呢？可以从两个维度回答这个问题：索引哪些情况会失效，索引不适合哪些场景 索引哪些情况会失效 查询条件包含or，会导致索引失效。隐式类型转换，会导致索引失效，例如age字段类型是int，我们where age = “1”，这样就会触发隐式类型转换。like通配符会导致索引失效。注意："ABC%“会走range索引，”%ABC"索引才会失效。联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。对索引字段进行函数运算。对索引列运算（如，+、-、*、/），索引失效。索引字段上使用（!= 或者 < >，not in）时，会导致索引失效。索引字段上使用is null， is not null，可能导致索引失效。相join的两个表的字符编码不同，不能命中索引，会导致笛卡尔积的循环计算mysql估计使用全表扫描要比使用索引快,则不使用索引。 索引不适合哪些场景 数据量少的不适合加索引更新比较频繁的也不适合加索引离散性低的字段不适合加索引（如性别） 2. MySQL 遇到过死锁问题吗，你是如何解决的？排查死锁的步骤： 查看死锁日志show engine innodb status;找出死锁Sql分析sql加锁情况模拟死锁案发分析死锁日志分析死锁结果 3. 日常工作中你是怎么优化SQL的？可以从这几个维度回答这个问题： 加索引避免返回不必要的数据适当分批量进行优化sql结构主从架构，提升读性能分库分表 4. 分库分表的设计分库分表方案，分库分表中间件，分库分表可能遇到的问题 分库分表方案 水平分库：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。水平分表：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。 常用的分库分表中间件 sharding-jdbcMycat 分库分表可能遇到的问题 事务问题：需要用分布式事务啦跨节点Join的问题：解决这一问题可以分两次查询实现跨节点的count,order by,group by以及聚合函数问题：分别在各个节点上得到结果后在应用程序端进行合并。数据迁移，容量规划，扩容等问题ID问题：数据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑UUID跨分片的排序分页问题（后台加大pagesize处理？） 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 写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引InnoDB 属于索引组织表，使用共享表空间和多表空间储存数据。MyISAM用.frm、.MYD、.MTI来储存表定义，数据和索引。 6. 数据库索引的原理，为什么要用 B+树，为什么不用二叉树？可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数，为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？ 为什么不是一般二叉树？1）当数据量大时，树的高度会比较高（树的高度决定着它的IO操作次数，IO操作耗时大），查询会比较慢。 2）每个磁盘块（节点/页）保存的数据太小（IO本来是耗时操作，每次IO只能读取到一个关键字，显然不合适），没有很好的利用操作磁盘IO的数据交换特性，也没有利用好磁盘IO的预读能力（空间局部性原理），从而带来频繁的IO操作。 为什么不是平衡二叉树呢？我们知道，在内存比在磁盘的数据，查询效率快得多。如果树这种数据结构作为索引，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块，但是平衡二叉树可是每个节点只存储一个键值和数据的，如果是B树，可以存储更多的节点数据，树的高度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。 那为什么不是B树而是B+树呢？1）B+Tree范围查找，定位min与max之后，中间叶子节点，就是结果集，不用中序回溯 2）B+Tree磁盘读写能力更强（叶子节点不保存真实数据，因此一个磁盘块能保存的关键字更多，因此每次加载的关键字越多） 3）B+Tree扫表和扫库能力更强（B-Tree树需要扫描整颗树，B+Tree树只需要扫描叶子节点） 详细参考：索引原理 7. 聚集索引与非聚集索引的区别 一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序； 何时使用聚集索引或非聚集索引？
方案一：如果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 SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id方案四：利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联） 9. 如何选择合适的分布式主键方案呢？ 数据库自增长序列或字段。UUID雪花算法Redis生成ID利用zookeeper生成唯一ID 10. 事务的隔离级别有哪些？MySQL的默认隔离级别是什么？什么是事务的隔离性？ 隔离性是指，多个用户的并发事务访问同一个数据库时，一个用户的事务不应该被其他用户的事务干扰，多个并发事务之间要相互隔离。 咱们举例子来说明： 建表语句： CREATE TABLE `T` ( `id` int(11) NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE = INNODB;数据列表： idname1xiaohong2zhangsan3lisi案例一： 事务A，先执行，处于未提交的状态： insert into T values(4, wangwu);事务B，后执行，也未提交： select * from T;如果事务B能够读取到(4, wangwu)这条记录，事务A就对事务B产生了影响，这个影响叫做“读脏”，读到了未提交事务操作的记录。 案例二： 事务A，先执行： select * from T where id=1;结果集为：1, xiaohong 事务B，后执行，并且提交： update T set name=hzy where id=1;commit; 事务A，再次执行相同的查询： select * from T where id=1;结果集为：1, hzy 这次是已提交事务B对事务A产生的影响，这个影响叫做“不可重复读”，一个事务内相同的查询，得到了不同的结果。 案例三： 事务A，先执行： select * from T where id>3;结果集为： NULL 事务B，后执行，并且提交： insert into T values(4, wangwu); commit;事务A，首次查询了id>3的结果为NULL，于是想插入一条为4的记录： insert into T values(4, hzy);结果集为： Error : duplicate key! 这次是已提交事务B对事务A产生的影响，这个影响叫做“幻读”。 可以看到，并发的事务可能导致其他事务： 读脏 不可重复读 幻读 InnoDB实现了四种不同事务的隔离级别： 读未提交(Read Uncommitted)读提交(Read Committed, RC)可重复读(Repeated Read, RR)串行化(Serializable)不同事务的隔离级别，实际上是一致性与并发性的一个权衡与折衷。 InnoDB的四种事务的隔离级别，分别是怎么实现的？ InnoDB使用不同的锁策略(Locking Strategy)来实现不同的隔离级别。 读未提交(Read Uncommitted)这种事务隔离级别下，select语句不加锁。 此时，可能读取到不一致的数据，即“读脏”。这是并发最高，一致性最差的隔离级别。 串行化(Serializable)这种事务的隔离级别下，所有select语句都会被隐式的转化为select … in share mode. 这可能导致，如果有未提交的事务正在修改某些行，所有读取这些行的select都会被阻塞住。 这是一致性最好的，但并发性最差的隔离级别。 在互联网大数据量，高并发量的场景下，几乎不会使用上述两种隔离级别。 可重复读(Repeated Read, RR) 这是InnoDB默认的隔离级别，在RR下：①普通的select使用快照读(snapshot read)，这是一种不加锁的一致性读(Consistent Nonlocking Read)，底层使用MVCC来实现； ②加锁的select(select … in share mode / select … for update), update, delete等语句，它们的锁，依赖于它们是否在唯一索引(unique index)上使用了唯一的查询条件(unique search condition)，或者范围查询条件(range-type search condition)： 在唯一索引上使用唯一的查询条件，会使用记录锁(record lock)，而不会封锁记录之间的间隔，即不会使用间隙锁(gap lock)与临键锁(next-key lock)范围查询条件，会使用间隙锁与临键锁，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻影行记录，以及避免不可重复的读 读提交(Read Committed, RC) 这是互联网最常用的隔离级别，在RC下：①普通读是快照读； ②加锁的select, update, delete等语句，除了在外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会封锁区间，其他时刻都只使用记录锁； 此时，其他事务的插入依然可以执行，就可能导致，读取到幻影记录。 11. 在高并发情况下，如何做到安全的修改同一行数据？要安全的修改同一行数据，就要保证一个线程在修改时其它线程无法更新这行记录。一般有悲观锁和乐观锁两种方案 使用悲观锁悲观锁思想就是，当前线程要进来修改数据时，别的线程都得拒之门外~ 比如，可以使用select…for update select * from User where name=‘jay’ for update以上这条sql语句会锁定了User表中所有符合检索条件（name=‘jay’）的记录。本次事务提交之前，别的线程都无法修改这些记录。 使用乐观锁乐观锁思想就是，有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。 12. 数据库的乐观锁和悲观锁 悲观锁悲观锁她专一且缺乏安全感了，她的心只属于当前事务，每时每刻都担心着它心爱的数据可能被别的事务修改，所以一个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进行修改啦，只能等待锁被释放才可以执行。 乐观锁乐观锁的“乐观情绪”体现在，它认为数据的变动不会太频繁。因此，它允许多个事务同时对数据进行变动。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。 13. SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义？ show status 命令了解各种 sql 的执行频率通过慢查询日志定位那些执行效率较低的 sql 语句explain 分析低效 sql 的执行计划（这点非常重要，日常开发中用它分析Sql，会大大降低Sql导致的线上事故） 14. select for update有什么含义，会锁表还是锁行还是其他？select for update 含义 select查询语句是不会加锁的，但是select for update除了有查询的作用外，还会加锁呢，而且它是悲观锁哦。至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。 没用索引/主键的话就是表锁，否则就是是行锁。 15. MySQL事务得四大特性以及实现原理 原子性： 事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。一致性： 指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。隔离性： 多个事务并发访问时，事务之间是相互隔离的，即一个事务不影响其它事务运行效果。简言之，就是事务之间是进水不犯河水的。持久性： 表示事务完成以后，该事务对数据库所作的操作更改，将持久地保存在数据库之中。 事务ACID特性的实现思想 原子性：是使用 undo log来实现的，如果事务执行过程中出错或者用户执行了rollback，系统通过undo log日志返回事务开始的状态。持久性：使用 redo log来实现，只要redo log日志持久化了，当系统崩溃，即可通过redo log把数据恢复。隔离性：通过锁以及MVCC,使事务相互隔离开。一致性：通过回滚、恢复，以及并发情况下的隔离性，从而实现一致性。 16. 如果某个表有近千万数据，CRUD比较慢，如何优化？ 分库分表某个表有近千万数据，可以考虑优化表结构，分表（水平分表，垂直分表），当然，你这样回答，需要准备好面试官问你的分库分表相关问题呀，如 分表方案（水平分表，垂直分表，切分规则hash等）分库分表中间件（Mycat，sharding-jdbc等）分库分表一些问题（事务问题？跨节点Join的问题）解决方案（分布式事务等） 索引优化除了分库分表，优化表结构，当然还有所以索引优化等方案~ 17. 如何写sql能够有效的使用到复合索引？复合索引，也叫组合索引，用户可以在多个列上建立索引,这种索引叫做复合索引。 当我们创建一个组合索引的时候，如(k1,k2,k3)，相当于创建了（k1）、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则。 select * from table where k1=A AND k2=B AND k3=D有关于复合索引，我们需要关注查询Sql条件的顺序，确保最左匹配原则有效，同时可以删除不必要的冗余索引。 18. mysql中in 和exists的区别假设表A表示某企业的员工表，表B表示部门表，查询所有部门的所有员工，很容易有以下SQL: select * from A where deptId in (select deptId from B);这样写等价于： 先查询部门表B select deptId from B 再由部门deptId，查询A的员工 select * from A where A.deptId = B.deptId 可以抽象成这样的一个循环： List resultSet ; for(int i=0;i |
【本文地址】
今日新闻 |
推荐新闻 |