mysql优化面试（面试问题，mysql处理什么数量级的数据时，性能会急剧下降）

本文目录

• 面试问题，mysql处理什么数量级的数据时，性能会急剧下降
• 每日一问-常见MySQL面试问题3
• 面试高阶php工程师，一般会问到哪些问题
• 面试官：mysql重启后自增id是从几开始增加
• 面试中常问：mysql数据库做哪些优化也提高mysql性能

面试问题，mysql处理什么数量级的数据时，性能会急剧下降

跟mysql版本有关系，如果是5.7的话，是几千万。但是5.7之后基本上就不用考虑数据量的问题了。但是这个问题问的不好，因为性能急剧下降不但但是跟数据量这一个因素有关系。
还有机器的配置，比如内存，如果内存放不下索引而把索引放在了虚拟内存上，那么效率就会急剧下降了。
还有就是sql建立合适的索引了。

每日一问-常见MySQL面试问题3

什么是数据库事务，MySQL 为什么会使用 InnoDB 作为默认选项?

1.原子性（一个原子事务中的所有操作要么全部成功，要么全部失败） 实现主要基于undo log（回滚日志）

2.一致性（数据库总是从一个一致性的状态转换到另一个一致性的状态）

3. 隔离性（针对并发事务而言，事务必须在不干扰其他进程或事务的前提下独立执行）

4.持久性（一旦事务提交成功，它对于数据的修改就会永久保存到数据库中）

也就是我们常说的事务ACID，这样才能保证事务中数据的正确性。

InnoDB支持事务安全，InnoDB支持表、行(默认)级锁，而MyISAM支持表级锁；

面试高阶php工程师，一般会问到哪些问题

面试高阶php工程师，一般会问到哪些问题

1. 高并发大访问量的mysql优化，伺服器优化？

栏位建索引、主从资料库、读写分离、表分割槽、负载均衡。

linux的慢查询日志会记录mysql的超时查询sql语句，定期察看进行优化。

2.大访问量下秒杀模组程式怎么设计，如果使用mysql会有多卖的情况，就是订单超过库存。

将订单资料快取到记忆体，如果用资料库直接崩掉，毫无悬念的。

3.快取的使用

能用静态的用静态，不能静态的用记忆体快取，例如memcache、redis，不能快取的用资料库。

4.session可不可以跨域？怎么跨域？

将PHP session机制重写（PHP提供），将session储存在memcache或者资料库就可以跨域了。

另外session能以三种方式储存，档案、资料库、快取。

5.了不了解非关系型资料库？

mongodb

6.会不会写shell指令码以及linux的操作

还会问一下时下流行的东西，比如做没做过微信开发，例如微信支付开发、APP移动开发，等等问题。

问的核心东西都是围绕这些转的，如果有笔试会让你写sql，php功能（例如气泡排序等排序），还有逻辑题。

我当初面试了很多，这是一个我的面试经验的总结，纯手打忘采纳。

高阶php工程师都做哪些工作？

释出任务，提出解决方案，解决核心程式码之类的。其它交给底下做。

面试三次元量测工程师会问哪些问题

其实，不管是什么样的面试形，问的问题都差不多，万变不离其宗，都有规律可寻。其实对所有的面试官而言，只有一个目的：在最短的时间里了解到你最多的资讯。想高效率的准备面试，先从这七个大方面着手吧！
一、基本情况
1、请用最简洁的语言描述您从前的工作经历和工作成果。
二、专业背景
您认为此工作岗位应当具备哪些素质？
三、工作模式
您平时习惯于单独工作还是团队工作？
四、价值取向
您对原来的单位和上司的看法如何？
五、资质特性
您如何描述自己的个性？
六、薪资待遇
是否方便告诉我您目前的待遇是多少？
七、背景调查
您是否介意我们通过您原来的单位迚行一些调查？
95%的面试基本上都离不开这些问题，当然还有可能问一些专业问题，我想如果你做过的话应该都不是什么难事，一般面试官都不会过多的问专业方面的问题的。以上资讯直接参考楚湘人才网面试宝典篇之化繁为简，把HR的上百道问题汇总成七大类和面试常问经典问题。更多更全面的面试资讯 面试技巧 面试问题请登陆楚湘人才网或关注微信公众平台：楚湘人才网

2015年高阶工程师答辩会问哪些问题

没有统一标准的，不同专业、不同专家会问不同问题，都是随机的，没有固定模式。

大疆面试硬体工程师，一般会问什么问题

分两类
1、会技术的面试官：会问你有没有做过一些小设计，如果这设计有点难度就会围绕这说，如果是普通货就会问你其它基础电路问题。
2、装13的人事部：闲聊日常生活，估算你对它们有没有用。

关于面试水电工程师会问哪些问题

1、水电工程师面试自我介绍
2、水利水电工程

什么是高阶PHP工程师

PHP技术人才，正迎合了目前的网际网路的发展趋势；PHP作为非常优秀的、简便的Web开发语言，和Linux，Apache，MySQL紧密结合，形成LAMP的开源黄金组合，不仅降低使用成本，还提升了开发速度，满足最新的互动式网路开发的应用，这使得php软体工程师成为一个发展迅速的职业。

面试机械工程师，技术部的一般会问那些问题？

兴趣、爱好、特长等各方面都可能问到。

在、技术方面的多从公司产品面问。
所以你要先了解这个公司的产品特性，看看合你专业相关的部分来准备。

面试php工程师出什么考题好

php的面试一般分为三个部分：笔试部分，会针对一些语法问题，常用基础技术问题，出一份试卷给你做；面试问题，针对你的简历，主管会经营询问验证，并对你进行综合打分；上机操作，会根据职位要求，要求你上线一个小功能之类的；总之，会结合岗位要求，对你的基本功、专业技能，以及综合素质进行简单的考核，一般不难！【如果对你有帮助，望采纳】

1.PHP基本功，字串与阵列
2.网路功能，发起curl，socket程式设计等
3.对网路开发的理解，tcp/udp, 协议的讨论
PS：对具体函式的掌握要求不高，反正可以查手册。

面试官：mysql重启后自增id是从几开始增加

在mysql中用自增列作为主键时，先往表里插入5条数据，此时表里数据id为1、2、3、4、5，如果此时删除id=4、5的数据后，再重启数据库，重启成功后向表里插入数据的时候，innodb、myisam引擎下ID分别是从几开始增加？ 如果你没经历过，或者当面试时被问到这个问题时，相信多数人都是一脸懵逼。MD 谁有事没事去重启线上数据库嘛。最主要的是很多没有测试过这个场景，没有这方面的经验，我在这里做个笔记，大家轻喷！

MySQL 通常使用的引擎都是 INNODB，在建表时，一般使用自增列作为表的主键，这样的表对提高性能有一定的帮助。但是自增列有一个坑，并且这个坑存在了很久，一直到 MySQL 8.0 版本，才修复了这个坑，这个坑就是表的自增列变量 auto_increment 在 MySQL 重启后，有可能丢失。

在 MySQL 低版本中，InnoDB 表中使用自增的 auto-increment 计数器 会把值存放在内存中，不会写入磁盘。一旦 MySQL 服务重启，这个值就丢了，InnoDB 引擎会根据表中现有的数据重新计算该计数器的值：获取表中最大的自增主键 ID 作为auto-increment 计数器的最大计数，当 insert 数据时，在 auto-increment 计数器最大值上 1。

先创建一张 user 表，新增几条数据：

向 user 表里插入 5 条数据，主键 ID 按自增列通过 auto-increment 计数器实现自增。

在 user 表里删除 id 为 4、5 的数据，再向 user 表中插入一条数据，主键 ID 是 auto-increment 的值 6。

mysql 数据库重启后，innodb 自增主键 ID 会根据 auto-increment 计数器的重置而重置。

在场景一的基础上，在删除 id 为 6、3 的数据后，此时 auto-increment 计数器的值为 7，user 表里的 id 最大是 2。

然后重启数据库后，auto-increment 计数器的值变为 3，也就是 user 表里的自增列 ID 的最大值 2 加 1。

此时在插入数据时，自增 ID 会从 3 开始自增。Innodb 表中把自增列作为主键 ID 时，在 mysql 重启后就会存在 ID 重置问题。**删除数据后，再重启，AUTO_INCREMENT 会查询表里最大 ID 并进行重置，重置后和重启前AUTO_INCREMENT 计数器的值不同。**在 MyISAM 引擎表中的自增列不会存在这个问题。

在 MySQL 8.0 中，这个计数器的逻辑变了：每当计数器的值有变，InnoDB 会将其写入 redo log，保存到引擎专用的系统表中。MySQL 正常关闭后重启：从系统表中获取计数器的数值。MySQL 故障后重启：从系统表中获取计数器的值；从最后一个检查点开始扫描 redo log 中记录的计数器值；取这两者的最大值作为新值。

总结

如果 mysql 重启了，那么 innodb 表在启动后，AUTO_INCREMENT 会自动检测出、并重置为当前表中自增列的最大值 +1。2）假如一个表格里 AUTO_INCREMENT 计数器的值是 10，此时执行update table set id = 15 where id = 9后，如果这时再继续插入数据，到了自增 ID=15 的时候是会报错。但是这个时候继续插入，就不会报错。因为刚才即使报错了，AUTO_INCREMENT 的值依旧会增加。3）现在使用的一般都是 innodb 引擎，如果将 myisam 引擎转换过来的时候，一定要小心这个引擎在自增 id 上的不同表现。在主从使用不同引擎的时候,也会出现问题，最好将引擎改完一致性的。

面试中常问：mysql数据库做哪些优化也提高mysql性能

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步操作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新操作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

• A：

• select * from t1 where f1 = 20;



• B：

• select * from t1 where f1 = 30;



如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 8.0 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

• mysql》 desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)



表记录数：


• mysql》 select count(*) from t1;+----------+| count(*) |+----------+|    32768 |+----------+1 row in set (0.01 sec)



这里我们两条经典的SQL：

• SQL C：

• select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;



• SQL D：

• select * from t1 where rank1 =100  and rank2 =100  and rank3 =100;



表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为3243.65。

• mysql》 explain  format=json select * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "3243.65"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": ,      "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))"    }  }}1 row in set, 1 warning (0.00 sec)



我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为441.09，明显比之前的快了好几倍。

• mysql》 explain  format=json select /*+ index_merge(t1) */ * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "441.09"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": ,      "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))"    }  }}1 row in set, 1 warning (0.00 sec)



我们再看下SQL D的计划：

• 不加HINT，

• mysql》 explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "534.34"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": ,      "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))"    }  }}1 row in set, 1 warning (0.00 sec)



• 加了HINT，

• mysql》 explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "5.23"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": ,      "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))"    }  }}1 row in set, 1 warning (0.00 sec)



对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。