本文共 2626 字，大约阅读时间需要 8 分钟。

mysql为什么需要优化

今天用一篇文章讲讲为什么sql需要优化，天天讲怎么优化，那么到底为啥需要优化呢？不知道各位同学有没有深思过这个问题。今天我们一起来思考一下。

先贴上Mysql的官方的一段话

当使用MyISAM存储引擎时，MySQL使用极快速的表锁定，以便允许多次读或一次写。使用该存储引擎的最大问题出现在同一个表中进行混合稳定数据流更新与慢速选择。如果这只是某些表的问题，你可以使用另一个存储引擎。参见第15章：存储引擎和表类型。​MySQL可以使用事务表和非事务表。为了更容易地让非事务表顺利工作(如果出现问题不能回滚)，MySQL采用下述规则。请注意这些规则只适用于不运行在严格模式下或为INSERT或UPDATE使用IGNORE规定程序时。所有列有默认值。请注意当运行在严格SQL模式(包括TRADITIONAL SQL模式)时，必须为NOT NULL列指定默认值。如果向列内插入不合适的或超出范围的值，MySQL将该列设定为“最好的可能的值”，而不是报告错误。对于数字值，为0、可能的最小值或最大值。对于字符串，为空字符串或列内可以保存的字符串。请注意当运行在严格模式或TRADITIONAL SQL模式时该行为不适用。所有表达式的计算结果返回一个表示错误状况的信号。例如，1/0返回NULL。(使用ERROR_FOR_DIVISION_BY_ZERO SQL模式可以更改该行为)。如果正使用非事务表，不应该使用MySQL来检查列的内容。一般情况，最安全的(通常是最快的)方法径是让应用程序确保只向数据库传递合法值。相关详细信息参见1.8.6节，“MySQL处理约束的方式”和13.2.4节，“INSERT语法”或5.3.2节，“SQL服务器模式”。

扎眼一看，我擦嘞，这说的是一些什么鬼，

第一句话，涉及到MyISAM，一种数据库存储引擎，相信各位对它有一定了解（只支持表锁）

那么他这句话什么意思呢？mysql使用极其快速的表锁定，以便多次读或一次写。也是就是共享读，排他写，读我们可以一起同时读取这张表的数据，但是写，在某一时刻，只能有一个线程建立写操作，这有什么问题吗？

第二句话就说了，使用该存储引擎的最大问题就是：在同一个表中进行混合稳定数据流更新与慢速选择。啥意思？

意思是：在同一张表中，如果我们想得到一个多个读写操作同时进行的时候，如果您使用这种存储引擎，那么我们能够保证这张表的数据都是稳定更新的，不会出现异常。因为并发情况下，数据写，不采取措施，就会有数据异常情况。

但是呢？会带来一个很大的问题，这张表的读写性能将极大降低，怎么讲？比如公共厕所，都是一个人上厕所，后面的人都不能进去，只能同时有一个人上厕所。那么效率不高，如果男厕（农村的有些）可以同时多个人同时上厕所。相较而言，哪种效率高？（哈哈，例子没举好，抱歉）

那Mysql就早知道这个问题？不解决一下吗？是的，mysql是一款热插拔性的数据库，支持插件式方式。也就是还提供了其他特性的数据库存储引擎供我们选择，只需要切换一下即可，那么其他的数据库存储引擎就会有解决这种问题的。这种操作，也就是将选择权利放给我们程序员，让我们自己去根据自己的业务情况，项目背景去选择适合的数据库存储引擎。

第二段：说到事务表和并非事务表（事务应该大家都是知道的）

所有列有默认值，请注意运行在严格SQL模式时，必须为NOT NULL的列指定默认值；

这是什么意思呢？这就是一种表结构设计规范了。也就是说如果我们对某个列设置为不为NULL，那么我们就必须对其指定默认值。

如果向列中插入了不合适的或超出范围的值，mysql会将该类设定为“最好的可能的值”，而不是报告错误。通俗来说，我设置一个列存储字符 varchar 100，这个时候，我往其存储 200个字符的字符串，但是mysql只会帮我记录前100个字符，而不是告诉我超出，抛出异常。

所有表达式的计算结果返回一个表示错误状况的信号。例如1/0返回null。这属于逻辑错误，语法错误。

那这些和事务表和非事务表有什么关系吗？

当然，如果是正在使用非事务的表正在执行一批sql，那恰好存在上述问题，那么就会出现后面所描述的情况，不会抛出异常，会做出默认的容错处理，为了保证sql的正常进行。

那但是我们通常来说，如果存在了列存不下的情况，我们更希望数据库能够返回错误给我们，而不是一声不吭。那么这也是非事务表的一个特性（此处不能说是弊端，只有合适和不合适）

那么很简单的两个例子，mysql为什么要举这些例子呢？

当然，我们大部分同学所理解的优化，只是针对使用上优化，但是上述两个例子，可能偏向于技术配置上的优化，但都属于我们需要考虑的点。

mysql这句话有一个标题“Mysql设计局限与折中”；我认为很有道理的。技术没有好坏之分，只有适合不适合之分。作为一个广受欢迎的开源、关系型数据库，占有大量的市场，那么就需要提供各种情况的特性，只有我们对其不同的特性进行插件式方式组合使用，搭配出最适合我们业务场景的数据库，这才是最优的。而不是我们局限于自己的眼光，觉得某个产品不行，这样就是bug。

回答上面的问题，为什么举这些例子，我觉得mysql就是想表达自己产品的特性，可以自由定制，但需要我们使用者了解其特性，才能对其进行更优的使用。

那么到底mysql为什么需要优化呢？其实mysql给我们提供一个稳定、高可用的数据库使用，但是如果我们不看说明书就去使用它，或许，我们可以一路踩着坑，慢慢的会发现其使用的方式，但是如果我们不去关注它，只考虑能用，可以用就行了。那么mysql这么一款优秀的产品，很多高级特性我们都忽略了。就好比我们一辆劳斯莱斯拉货，是的，12缸，动力贼强，什么货不能拉？拉一头牛绰绰有余，但是如果用好他，我们可以拉10头牛，试问不是众望所归吗？

优化本质上来说，是一个很广的概念，对于数据库层面的优化，我们很多种点都可以考虑。

数据库缓存大小配置合理，那也是一种优化；表结构设计合理，也是优化；SQL写好了，也是优化；数据库连接方式用好了，也是优化；

所以我认为优化是一种细节都应该考虑的问题，比如我们sql的优雅可读，我也认为是优化。

数据库关系着整个应用的数据信息，是一个应用最核心的组成。我认为数据库用好了，应用的使用也有质的飞跃。

后面我会针对每个细节，都举一些实例来说说，优化具体；

转载地址：https://changemax.blog.csdn.net/article/details/113075366 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！