mysql目前用的版本？
5.1.21；目前最高5.7.*
left join，right join，inner join？
left join(左连接) 返回包括左表中的所有记录和右表中连接字段相等的记录
right join(右连接) 返回包括右表中的所有记录和左表中连接字段相等的记录
左连接和右连接很像只是顺序问题。
inner join(等值连接、内连接) 只返回两个表中连接字段相等的行
MySQL 分页查询语句
select * from table limit (start-1)*limit,limit; 其中start是页码，limit是每页显示的条数
脏读、幻读、不可重复读?
https://blog.csdn.net/w372426096/article/details/80798062
数据库的几大范式?
第一范式----数据库中的表(所有字段值)都是不可分割的原子数据项。
第二范式----数据库表中的每一列都和主键相关，而不能只和主键的某一部分相关。也就是说 一个表中只能只能包含一个，不能把多种数据保存在同一个表中。
第三范式----数据库表中每一列数据都和主键直接相关，不能间接相关。
数据库常见的命令?
https://www.cnblogs.com/zhouzetian/p/6429181.html
注意truncat,drop（DDL）,delete(操作语句)区别
DDL、DML、DCL分别指什么？
一、DDL :数据定义语言，用于定义和管理 SQL 数据库中的所有对象的语言
1.CREATE - to create objects in the database 创建
2.ALTER - alters the structure of the database 修改
3.DROP - delete objects from the database 删除
4.TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed
Truncate table 表名 速度快,而且效率高,因为:
TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。
DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。
TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。
对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。
TRUNCATE TABLE 不能用于参与了索引视图的表。
5.COMMENT - add comments to the data dictionary 注释
6.GRANT - gives user's access privileges to database 授权
7.REVOKE - withdraw access privileges given with the GRANT command 收回已经授予的权限
二、DML:数据操作语言，SQL中处理数据等操作统称为数据操纵语言
1.SELECT - retrieve data from the a database 查询
2.INSERT - insert data into a table 添加
3.UPDATE - updates existing data within a table 更新
4.DELETE - deletes all records from a table, the space for the records remain 删除
5.CALL - call a PL/SQL or Java subprogram
6.EXPLAIN PLAN - explain access path to data
7.LOCK TABLE - control concurrency 锁，用于控制并发
三、DCL:数据控制语言，用来授予或回收访问数据库的某种特权，并控制数据库操纵事务发生的时间及效果，对数据库实行监视等
1.COMMIT - save work done 提交
2.SAVEPOINT - identify a point in a transaction to which you can later roll back 保存点
3.ROLLBACK - restore database to original since the last COMMIT 回滚
4.SET TRANSACTION - Change transaction options like what rollback segment to use 设置当前事务的特性，它对后面的事务没有影响．
SQL的整个解析、执行过程原理、SQL行转列；
将一个链表反转（用三个指针，但是每次只发转一个）
sql语句各种条件的执行顺序，如select， where， order by， group by
查看执行计划
索引
SQL 索引的顺序，字段的顺序？
最左原则?
数据库的索引实现和非主键的二级索引？
MySQL 索引使用的注意事项
最重要的索性及底层实现
索引类别（B+树索引、全文索引、哈希索引）、索引的原理？
什么是自适应哈希索引（AHI）？
为什么要用 B+tree作为MySQL索引的数据结构？
聚集索引与非聚集索引的区别？
遇到过索引失效的情况没，什么时候可能会出现，如何解决？
索引失效的场景
优化：
常见的数据库优化方案？
第一阶段 优化sql和索引
这一步成本最低啊，不需要加什么中间件。你没经过索引优化和SQL优化。
步骤大概
-
用慢查询日志定位执行效率低的
SQL语句 -
用
explain分析SQL的执行计划 -
确定问题，采取相应的优化措施，建立索引啊，等
第二阶段 搭建缓存
在优化sql无法解决问题的情况下，才考虑搭建缓存。毕竟你使用缓存的目的，就是将复杂的、耗时的、不常变的执行结果缓存起来，降低数据库的资源消耗。
这里需要注意的是:搭建缓存后，系统的复杂性增加了。你需要考虑很多问题，比如:
-
缓存和数据库一致性问题？(比如是更缓存，还是删缓存),这点可以看我的一篇文章《数据库和缓存双写一致性方案解析》。
-
缓存击穿、缓存穿透、缓存雪崩问题如何解决？是否有做缓存预热的必要。不过我猜，大部分中小公司应该都没考虑。这点可以看我的另一篇《分布式之redis复习精讲》
第三阶段 读写分离
缓存也搞不定的情况下，搞主从复制，上读写分离。在应用层，区分读写请求。或者利用现成的中间件 mycat或者 altas等做读写分离。
需要注意的是,只要你敢说你用了主从架构，有三个问题，你要准备:
1.主从的好处？
回答:实现数据库备份，实现数据库负载均衡，提高数据库可用性
2.主从的原理?
回答:如图所示（图片不是自己画的，偷懒了）
主库有一个 logdump线程，将 binlog传给从库
从库有两个线程，一个I/O线程，一个SQL线程，I/O线程读取主库传过来的 binlog内容并写入到 relay log,SQL线程从 relay log里面读取内容，写入从库的数据库。
3.如何解决主从一致性?
回答:这个问题，我不建议在数据库层面解决该问题。根据 CAP 定理，主从架构本来就是一种高可用架构，是无法满足一致性的。 哪怕你采用同步复制模式或者半同步复制模式，都是弱一致性，并不是强一致性。所以，推荐还是利用缓存，来解决该问题。
步骤如下:
-
自己通过测试，计算主从延迟时间，建议mysql版本为5.7以后，因为mysql自5.7开始，多线程复制功能比较完善，一般能保证延迟在1s内。不过话说回来，mysql现在都出到8.x了，还有人用5.x的版本么。
-
数据库的写操作，先写数据库，再写cache，但是有效期很短，就比主从延时的时间稍微长一点。
-
读请求的时候，先读缓存，缓存存在则直接返回。如果缓存不存在(这时主从同步已经完成)，再读数据库。
第四阶段 利用分区表
说句实在话，你们面试的时候，其实可以略过这个阶段。因为很多互联网公司都不建议用分区表，我自己也不太建议用分区表，采用这个分区表，坑太多。
这里引用一下其他文章的回答:
什么是mysql的分区表？
回答：所有数据还在一个表中，但物理存储根据一定的规则放在不同的文件中。这个是mysql支持的功能，业务代码不需要改动，但是sql语句需要改动，sql条件需要带上分区的列。
缺点
-
分区键设计不太灵活，如果不走分区键，很容易出现全表锁
-
在分区表使用
ALTER TABLE…ORDER BY，只能在每个分区内进行orderby。 -
分区表的分区键创建索引，那么这个索引也将被分区。分区键没有全局索引一说。
-
自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定该去哪个分区查，不太可控。 …不列举了，不推荐
第五阶段 垂直拆分
上面四个阶段都没搞定，就来垂直拆分了。垂直拆分的复杂度还是比水平拆分小的。将你的表，按模块拆分为不同的小表。大家应该都看过《大型网站架构演变之路》，这种类型的文章或者书籍，基本都有提到这一阶段。
如果你有幸能够在什么运营商、银行等公司上班，你会发现他们一个表，几百个字段都是很常见的事情。所以，应该要进行拆分，拆分原则一般是如下三点:
-
把不常用的字段单独放在一张表。
-
把常用的字段单独放一张表
-
经常组合查询的列放在一张表中（联合索引）。
第六阶段 水平拆分
OK,水平拆分是最麻烦的一个阶段，拆分后会有很多的问题，我再强调一次，水平拆分一定是最最最最后的选择。从某种意义上，我觉得还不如垂直拆分。因为你用垂直拆分，分成不同模块后，发现单模块的压力过大，你完全可以给该模块单独做优化，例如提高该模块的机器配置等。如果是水平拆分，拆成两张表，代码需要变动，然后发现两张表还不行，再变代码，再拆成三张表的？水平拆分后，各模块间耦合性太强，成本太大，慎重。
在你的项目中数据库如何进行优化的？
慢sql优化，缓存，读写分离，设计表时候垂直拆分，终极水平拆分
SQL 优化的常见方法有哪些？
explain命令？
https://blog.csdn.net/w372426096/article/details/82421378
对于SQL慢查询的优化？（主要是从查询语句和数据库表设计两个方面来考虑，查询语句方面可以增加索引，增加查询筛选的限制条件；数据库表设计的时候可以拆分表，设计得更细粒度。但是后来才发现面试官想要的就是查询大量数据的慢查询问题的优化。）
MySQL遇到的死锁问题、如何排查与解决？
limit 20000 加载很慢怎么解决？
select xx from xx where xx and xx order by xx limit xx； 如何优化这个（看explain）
事务：
mysql是如何实现事务的
MySQL 事务特性及特性和隔离级别
数据库事务ACID（原子性、一致性、隔离性、持久性）？
事务的隔离级别（读未提交、读以提交、可重复读、可序列化读）？
事务介绍，分布式事物的理解，常见的解决方案有哪些，什么事两阶段提交、三阶段提交；
分布式事务的原理2阶段提交，同步\异步\阻塞\非阻塞；
数据库事务隔离级别，MySQL默认的隔离级别、Spring如何实现事务、JDBC如何实现事务、嵌套事务实现、分布式事务实现；
引擎
存储引擎的 InnoDB与MyISAM区别，优缺点，使用场景
mysql的存储引擎,区别
innodb对一行数据的读会枷锁吗？不枷锁，读实际读的是副本
myisam的优点，和innodb的区别
求表的size，或做数据统计可用什么存储引擎
读多写少可用什么引擎
假如要统计多个表应该用什么引擎
分表分库
说说分库与分表设计
分库与分表带来的分布式困境与应对之策（如何解决分布式下的分库分表，全局表？）
锁
MySQL锁，悲观锁、乐观锁、排它锁、共享锁、表级锁、行级锁；
乐观锁的业务场景及实现方式；
mysql的行级锁加在哪个位置
如何选择合适的分布式主键方案
选择合适的数据存储方案
分布式
读写分离何时强制要读主库，读哪个从库是通过什么方式决定的，从库的同步mysql用的什么方式
主从复制
MySQL记录binlog的方式主要包括三种模式？每种模式的优缺点是什么？
对表做统计时可直接看schema info信息，即查看表的系统信息
mysql的binlog
bin log主从复制
统计100G的ip文件中出现ip次数最多的100个ip
不可重复读会出现在什么场景？
项目 MySQL 的数据量和并发量有多大？
mvcc,Next-Key Lock