Mysql面试题

Mysql相关

1、MySQL服务器默认端口是什么?

MySQL服务器的默认端口是3306。

 

2、如何获取当前的MySQL版本?

SELECT VERSION();用于获取当前MySQL的版本。

 

3、MySQL驱动程序是什么?

以下是MySQL中可用的驱动程序：

• PHP驱动程序
• JDBC驱动程序
• ODBC驱动程序
• CWRAPPER
• PYTHON驱动程序
• PERL驱动程序
• RUBY驱动程序
• CAP11PHP驱动程序
• Ado.net5.mxj

 

4、如何使用Unix shell登录MySql?

# [mysql dir]/bin/mysql -h hostname -u -p

 

5、 myisamchk是用来做什么的?

压缩MyISAM表，减少磁盘或内存使用。

 

6、MYSQL数据库服务器性能分析的方法命令有哪些?

https://www.cnblogs.com/fan-yuan/p/8476207.html

mysql> show variables like '%slow%';

慢查询，执行时间超过2秒的即为慢查询，可以通过分析慢查询日志，找出有问题的SQL语句。

mysql> show variables like 'max_connections';

连接数，经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，另外一种情况是MySQL配置文件中max_connections值过小。

 

7、Mysql查询是否区分大小写?

不区分

 

8、如何输入字符为十六进制数字?

如果想输入字符为十六进制数字，可以输入带有单引号的十六进制数字和前缀(X)，或者只用(Ox)前缀输入十六进制数字。

如果表达式上下文是字符串，则十六进制数字串将自动转换为字符串。

 

9、如何显示前50行?

在MySql中，使用以下代码查询显示前50行：

SELECT *FROM LIMIT 0,50;

 

10、可以使用多少列创建索引?

任何标准表最多可以创建16个索引列。

 

11、MySql表中允许有多少种TRIGGERS?

在MySql表中允许有六种触发器，如下：

• BEFORE INSERT
• AFTER INSERT
• BEFORE UPDATE
• AFTER UPDATE
• BEFORE DELETE and
• AFTER DELETE

 

12、NOW()和CURRENT_DATE()有什么区别?

NOW()命令用于显示当前年份，月份，日期，小时，分钟和秒。

CURRENT_DATE()仅显示当前年份，月份和日期。

 

13、什么是通用SQL函数?

CONCAT(A, B) - 连接两个字符串值以创建单个字符串输出。

FORMAT(X, D)- 格式化数字X到D有效数字。

CURRDATE(), CURRTIME()- 返回当前日期或时间。

NOW() - 将当前日期和时间作为一个值返回。

MONTH()，DAY()，YEAR()，WEEK()，WEEKDAY() - 从日期值中提取给定数据。

HOUR()，MINUTE()，SECOND() - 从时间值中提取给定数据。

DATEDIFF(A，B) - 确定两个日期之间的差异，通常用于计算年龄

SUBTIMES(A，B) - 确定两次之间的差异。

FROMDAYS(INT) - 将整数天数转换为日期值。

 

14、解释访问控制列表

ACL(访问控制列表)是与对象关联的权限列表。这个列表是MySQL服务器安全模型的基础，它有助于排除用户无法连接的问题。

MySQL将ACL(也称为授权表)缓存在内存中。当用户尝试认证或运行命令时，MySQL会按照预定的顺序检查ACL的认证信息和权限。

 

15、mysql_fetch_array和mysql_fetch_object的区别是什么?

mysql_fetch_array() - 将结果行作为关联数组或来自数据库的常规数组返回。

mysql_fetch_object - 从数据库返回结果行作为对象。

 

16、我们如何在mysql中运行批处理模式?

以下命令用于在批处理模式下运行：

mysql;

mysql mysql.out

 

17、MySQL的复制原理以及流程

1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句；

 

MySQL复制的线程有几个及之间的关联

MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行；

 

18、MySQL如何保证复制过程中数据一致性及减少数据同步延时

一致性主要有以下几个方面：

1、在 MySQL5.5 以及之前， slave 的 SQL 线程执行的 relay log 的位置只能保存在文件（ relay-log.info）里面，并且该文件默认每执行 10000 次事务做一次同步到磁盘， 这意味着 slave 意外 crash 重启时， SQL 线程执行到的位置和数据库的数据是不一致的，将导致复制报错，如果不重搭复制，则有可能会 导致数据不一致。 MySQL 5.6 引入参数 relay_log_info_repository，将该参数设置为 TABLE 时， MySQL 将 SQL 线程执行到的位置存到mysql.slave_relay_log_info 表，这样更新该表的位置和 SQL 线程执行的用户事务绑定成一个事务，这样 slave 意外宕机后， slave 通过 innodb 的崩溃 恢复可以把 SQL 线程执行到的位置和用户事务恢复到一致性的状态。 2、 MySQL 5.6 引入 GTID 复制，每个 GTID 对应的事务在每个实例上面最多执行一次， 这极大地提高了复制的数据一致性； 3、MySQL 5.5 引入半同步复制， 用户安装半同步复制插件并且开启参数后，设置超时时间，可保证在超时时间内如果 binlog 不传到 slave 上面，那么用户提交事务时不会返回，直到超时后切成异步复制，但是如果切成异步之前用户线程提交时在 master 上面等待的时候，事务已经提交，该事务对 master 上面的其他 session 是可见的，如果这时 master 宕机，那么到 slave 上面该事务又不可见了，该问题直到 5.7 才解决； 4、MySQL 5.7 引入无损半同步复制，引入参 rpl_semi_sync_master_wait_point，该参数默认为 after_sync，指的是在切成半同步之前，事务不提交，而是接收到 slave 的 ACK 确认之后才提交该事务，从此，复制真正可以做到无损的了。 5、可以再说一下 5.7 的无损复制情况下， master 意外宕机，重启后发现有 binlog没传到 slave 上面，这部分 binlog 怎么办？？？分 2 种情况讨论， 1 宕机时已经切成异步了， 2 是宕机时还没切成异步？？？ 这个怎么判断宕机时有没有切成异步呢？？？ 分别怎么处理？？？

 

延时性：

5.5 是单线程复制， 5.6 是多库复制（对于单库或者单表的并发操作是没用的）， 5.7 是真正意义的多线程复制，它的原理是基于 group commit， 只要master 上面的事务是 group commit 的，那 slave 上面也可以通过多个 worker线程去并发执行。 和 MairaDB10.0.0.5 引入多线程复制的原理基本一样。

(4)、工作遇到的复制 bug 的解决方法

5.6 的多库复制有时候自己会停止，我们写了一个脚本重新 start slave;待补充…

 

19、MySQL binlog的几种日志录入格式以及区别

(1)、 各种日志格式的涵义

1.Statement：每一条会修改数据的sql都会记录在binlog中。 优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能 与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，

但是考虑到如果带条 件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所 产生的日志量会增加多少，以及带来的IO性能问题。) 缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的 一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,

像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题). 使用以下函数的语句也无法被复制： * LOAD_FILE() * UUID() * USER() * FOUND_ROWS() * SYSDATE() (除非启动时启用了 --sysdate-is-now 选项) 同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁 2.Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。 优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下 每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题 缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，

由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。 3.Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，

也就是在Statement和Row之间选择 一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。

 (2)、适用场景

在一条 SQL 操作了多行数据时， statement 更节省空间， row 更占用空间。但是 row模式更可靠。

(3)、结合第一个问题，每一种日志格式在复制中的优劣

Statement 可能占用空间会相对小一些，传送到 slave 的时间可能也短，但是没有 row模式的可靠。 Row 模式在操作多行数据时更占用空间， 但是可靠。

 

20、下MySQL数据库cpu飙升到500%的话他怎么处理？

当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，

看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整(比如说加索引、改 sql、改内存参数)之后，再重新跑这些 SQL。也有可能是每个 sql 消耗资源并不多，但是突然之间， 有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等

 

21、备份计划，mysqldump以及xtranbackup的实现原理

(1)、备份计划

视库的大小来定，一般来说 100G 内的库，可以考虑使用 mysqldump 来做，因为 mysqldump更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump 备份 出来的文件比较小，压缩之后更小)。100G 以上的库，可以考虑用 xtranbackup 来做，备份速度明显要比 mysqldump 要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。

(2)、备份恢复时间

物理备份恢复快，逻辑备份恢复慢这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考 20G的2分钟（mysqldump） 80G的30分钟(mysqldump) 111G的30分钟（mysqldump) 288G的3小时（xtra) 3T的4小时（xtra) 逻辑导入时间一般是备份时间的5倍以上

(3)、备份恢复失败如何处理

首先在恢复之前就应该做足准备工作，避免恢复的时候出错。比如说备份之后的有效性检查、权限检查、空间检查等。如果万一报错，再根据报错的提示来进行相应的调整。

(4)、mysqldump和xtrabackup实现原理

mysqldump

mysqldump 属于逻辑备份。加入--single-transaction 选项可以进行一致性备份。后台进程会先设置 session 的事务隔离级别为 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ)，

之后显式开启一个事务(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */)，这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。 如果加上--master-data=1 的话，在刚开始的时候还会加一个数据库的读锁(FLUSH TABLES WITH READ LOCK),等开启事务后，再记录下数据库此时 binlog 的位置(showmaster status)，马上解锁，再读取表的数据。等所有的数据都已经导完，就可以结束事务

Xtrabackup:

xtrabackup 属于物理备份，直接拷贝表空间文件，同时不断扫描产生的 redo 日志并保存下来。最后完成 innodb 的备份后，会做一个 flush engine logs 的操作(老版本在有 bug，在5.6 上不做此操作会丢数据)，确保所有的 redo log 都已经落盘(涉及到事务的两阶段提交 概念，因为 xtrabackup 并不拷贝 binlog，所以必须保证所有的 redo log 都落盘，否则可能会丢最后一组提交事务的数据)。这个时间点就是 innodb 完成备份的时间点，数据文件虽然不是一致性的，但是有这段时间的 redo 就可以让数据文件达到一致性(恢复的时候做的事 情)。然后还需要 flush tables with read lock，把 myisam 等其他引擎的表给备份出来，备份完后解锁。 这样就做到了完美的热备。

 

22、500台db，在最快时间之内重启

可以使用批量 ssh 工具 pssh 来对需要重启的机器执行重启命令。 也可以使用 salt（前提是客户端有安装 salt）或者 ansible（ ansible 只需要 ssh 免登通了就行）等多线程工具同时操作多台服务器

 

23、如何从mysqldump产生的全库备份中只恢复某一个库、某一张表？

全库备份 [root@HE1 ~]# mysqldump -uroot -p --single-transaction -A --master-data=2 >dump.sql 只还原erp库的内容 [root@HE1 ~]# mysql -uroot -pMANAGER erp --one-database

 

24、关于有丰富的线上恢复经验的

线上数据量有多大，如果是 100G，你用 mysqldump 出来要多久，然后 mysql进去又要多久，如果互联网不允许延时的话，你又怎么做到 恢复单张表的时候保证 nagios不报警。如果有人说 mysqldump 出来 1 个小时就 ok 了，那么我就要问问他 db 服务器是 啥配置了，如果他说 mysql 进去 50 分钟搞定了，那么我也要问问他 db 机器啥配置了，如果是普通的吊丝 pc server，那么真实性，大家懂得。然后如果你用 xtrabackup 备份要多久，恢复要多久，大家都知道 copy-back 这一步要很久，那么你有没有办法对这一块优化。

 

25、以下哪些手段可保证数据库中数据的完整性和一致性：

(1)自定义数据类型 (2)触发器 (3)主键和外键 (4)事务

答案： (1)(2)(3)(4) （为什么有1）

 

26、下列属于关系型数据库的是（）

A. Oracle    B MySql    C IMS     D MongoDB

AB，IMS（Information Management System ）数据库是IBM公司开发的两种数据库类型之一; 

一种是关系数据库，典型代表产品：DB2；另一种则是层次数据库，代表产品：IMS层次数据库。

非关系型数据库有MongoDB、memcachedb、Redis等。

 

27、mysql查询字段区不区分大小写？

不区分，哪怕值也不区分

 

28、数据库自增主键可能的问题。

在分库分表时可能会生成重复主键 利用自增比例达到唯一 自增1 2,3 等 

https://yq.aliyun.com/articles/38438

 

29、数据库连接池的原理

参考http://blog.csdn.net/shuaihj/article/details/14223015

 

30、简单说说数据库集群和负载均衡、分布式

解答：数据库负载均衡和集群参考 ，参考2