java反序列化漏洞修复⽅案，看完必懂数据库
1. MySQL 索引使⽤有哪些注意事项呢？
可以从三个维度回答这个问题：索引哪些情况会失效，索引不适合哪些场景，索引规则论文汇编怎么读
索引哪些情况会失效
查询条件包含or，可能导致索引失效
如何字段类型是字符串，where时⼀定⽤引号括起来，否则索引失效
like通配符可能导致索引失效。
联合索引，查询时的条件列不是联合索引中的第⼀个列，索引失效。
在索引列上使⽤mysql的内置函数，索引失效。
对索引列运算（如，+、-、*、/），索引失效。
vba数组添加数据索引字段上使⽤（！= 或者 < >，not in）时，可能会导致索引失效。
索引字段上使⽤is null， is not null，可能导致索引失效。
左连接查询或者右连接查询查询关联的字段编码格式不⼀样，可能导致索引失效。
mysql估计使⽤全表扫描要⽐使⽤索引快，则不使⽤索引。
索引不适合哪些场景
if三个条件怎么填写
数据量少的不适合加索引
更新⽐较频繁的也不适合加索引
区分度低的字段不适合加索引（如性别）
索引的⼀些潜规则
覆盖索引
回表
索引数据结构（B+树）
最左前缀原则
索引下推
2. MySQL 遇到过死锁问题吗，你是如何解决的？
我排查死锁的⼀般步骤是酱紫的：
查看死锁⽇志show engine innodb status;
出死锁Sql
分析sql加锁情况
模拟死锁案发
分析死锁⽇志
分析死锁结果
3. ⽇常⼯作中你是怎么优化SQL的？
mysql语句的执行顺序
可以从这⼏个维度回答这个问题：
加索引
避免返回不必要的数据
适当分批量进⾏
优化sql结构
分库分表
读写分离
4. 说说分库与分表的设计
分库分表⽅案，分库分表中间件，分库分表可能遇到的问题
分库分表⽅案:
⽔平分库：以字段为依据，按照⼀定策略（hash、range等），将⼀个库中的数据拆分到多个库中。
⽔平分表：以字段为依据，按照⼀定策略（hash、range等），将⼀个表中的数据拆分到多个表中。
垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
常⽤的分库分表中间件：
sharding-jdbc（当当）
Mycat
TDDL（淘宝）
Oceanus(58同城数据库中间件)
vitess（⾕歌开发的数据库中间件）
Atlas(Qihoo 360)
分库分表可能遇到的问题
事务问题：需要⽤分布式事务啦
跨节点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可以没有主键springmvc面试题常问2020
Innodb表需要更多的内存和存储，⽽MyISAM可被压缩，存储空间较⼩，。
Innodb按主键⼤⼩有序插⼊，MyISAM记录插⼊顺序是，按记录插⼊顺序保存。
InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能⼒的事务安全，与 MyISAM ⽐ InnoDB 写的效率差⼀些，并且会占⽤更多的磁盘空间以保留数据和索引
6. 数据库索引的原理，为什么要⽤ B+树，为什么不⽤⼆叉树？
可以从⼏个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查磁盘次数，为什么不是⼆叉树，为什么不是平衡⼆叉树，为什么不是B树，⽽偏偏是B+树呢？
为什么不是⼀般⼆叉树？
如果⼆叉树特殊化为⼀个链表，相当于全表扫描。平衡⼆叉树相⽐于⼆叉查树来说，查效率更稳定，总体的查速度也更快。
为什么不是平衡⼆叉树呢？
我们知道，在内存⽐在磁盘的数据，查询效率快得多。如果树这种数据结构作为索引，那我们每查⼀次数据就需要从磁盘中读取⼀个节点，也就是我们说的⼀个磁盘块，但是平衡⼆叉树可是每个节点只存储⼀个键值和数据的，如果是B树，可以存储更多的节点数据，树的⾼度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。
那为什么不是B树⽽是B+树呢？
1）B+树⾮叶⼦节点上是不存储数据的，仅存储键值，⽽B树节点中不仅存储键值，也会存储数据。innodb中页的默认⼤⼩是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的⼦节点树）就会更⼤，树就会更矮更胖，如此⼀来我们查数据进⾏磁盘的IO次数有会再次减少，数据查询的效率也会更快。
2）B+树索引的所有数据均存储在叶⼦节点，⽽且数据是按照顺序排列的，链表连着的。那么B+树使
得范围查，排序查，分组查以及去重查变得异常简单。
7. 聚集索引与⾮聚集索引的区别
⼀个表中只能拥有⼀个聚集索引，⽽⾮聚集索引⼀个表可以存在多个。
聚集索引，索引中键值的逻辑顺序决定了表中相应⾏的物理顺序；⾮聚集索引，索引中索引的逻辑顺序与磁盘上⾏的物理存储顺序不同。
索引是通过⼆叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。⽽⾮聚簇索引的叶节点仍然是索引节点，只不过有⼀个指针指向对应的数据块。
聚集索引：物理存储按照索引排序；⾮聚集索引：物理存储不按照索引排序；
何时使⽤聚集索引或⾮聚集索引？
8. limit 1000000 加载很慢的话，你是怎么解决的呢？
⽅案⼀：如果id是连续的，可以这样，返回上次查询的最⼤记录(偏移量)，再往下limit
select id，name from employee where id>1000000 limit 10.
⽅案⼆：在业务允许的情况下限制页数：
maxlength是什么意思建议跟业务讨论，有没有必要查这么后的分页啦。因为绝⼤多数⽤户都不会往后翻太多页。
⽅案三：order by + 索引（id为索引）
select id，name from employee order by id  limit 1000000，10
⽅案四：利⽤延迟关联或者⼦查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联）SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id
9. 如何选择合适的分布式主键⽅案呢？
数据库⾃增长序列或字段。
UUID。
Redis⽣成ID
Twitter的snowflake算法
利⽤zookeeper⽣成唯⼀ID
MongoDB的ObjectId
10. 事务的隔离级别有哪些？MySQL的默认隔离级别是什么？
读未提交（Read Uncommitted）
读已提交（Read Committed）
可重复读（Repeatable Read）
串⾏化（Serializable）
Mysql默认的事务隔离级别是可重复读(Repeatable Read)
11. 什么是幻读，脏读，不可重复读呢？
事务A、B交替执⾏，事务A被事务B⼲扰到了，因为事务A读取到事务B未提交的数据，这就是脏读
在⼀个事务范围内，两个相同的查询，读取同⼀条记录，却返回了不同的数据，这就是不可重复读。
事务A查询⼀个范围的结果集，另⼀个并发事务B往这个范围中插⼊/删除了数据，并静悄悄地提交，然后事务A再次查询相同的范围，两次读取得到的结果集不⼀样了，这就是幻读。
12. 在⾼并发情况下，如何做到安全的修改同⼀⾏数据？
要安全的修改同⼀⾏数据，就要保证⼀个线程在修改时其它线程⽆法更新这⾏记录。⼀般有悲观锁和乐观锁两种⽅案~
使⽤悲观锁
悲观锁思想就是，当前线程要进来修改数据时，别的线程都得拒之门外~ ⽐如，可以使⽤select…for update ~
select * from User where name=‘jay’ for update
以上这条sql语句会锁定了User表中所有符合检索条件（name=‘jay’）的记录。本次事务提交之前，别的线程都⽆法修改这些记录。
使⽤乐观锁
乐观锁思想就是，有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。实现⽅式：乐观锁⼀般会使⽤版本号机制或CAS算法实现。
13. 数据库的乐观锁和悲观锁。
悲观锁：
悲观锁她专⼀且缺乏安全感了，她的⼼只属于当前事务，每时每刻都担⼼着它⼼爱的数据可能被别的事务修改，所以⼀个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进⾏修改啦，只能等待锁被释放才可以执⾏。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。