这篇文章主要给大家介绍了关于mysql数据库常见的优化操作，文章总结的都是个人日常开发使用mysql数据库的经验所得，其中包括index索引、少用select*、explain select以及开启查询缓存等相关资料，相信会对大家具有一定的参考价值，需要的朋友们下面来一起看看吧。
前言
对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。所以mysql数据库的优化操作大家都要有所了解，本文就主要总结了mysql数据库中常见的优化操作，下面话不多说了，来看看详细的介绍吧。
一、Index索引
将Index放第一位，不用说，这种优化方式我们一直都在悄悄使用，那便是主键索引。有时候我们可能并不在意，如果定义适合的索引，数据库查询性能(速度)将提高几倍甚至几十倍。
普通索引
作用是提高查询速度。
建表，创建索引
CREATE TABLE tbl_name(字段名称 字段类型 [完整性约束条件],~index [索引名] (column_name));
创建索引
CREATE INDEX index_name ON tab_name (column_name)
删除索引
DROP INDEX index_name FROM tab_name
查看索引
SHOW index FROM tab_name
主键索引
作用是加速查询和唯一约束
建表，创建索引
CREATE TABLE tbl_name(字段名称 字段类型 [完整性约束条件],~PRIMARY KEY(column_name));
创建索引
ALTER TABLE tab_name ADD PRIMARY KEY(column_name)
删除索引
ALTER TABLE tab_name DROP PRIMAY KEY(column_name)
唯一索引
作用是加速查询和唯一约束
建表，创建索引
CREATE TABLE tbl_name(字段名称 字段类型 [完整性约束条件],~unique [索引名] (column_name));
创建索引
CREATE UNIQUE INDEX index_name ON tab_name (column_name)
删除索引
DROP UNIQUE INDEX index_name FROM tab_name
二、少用SELECT*
可能有的人查询数据库时，遇到要查询的都会select，这是不恰当的行为。我们应该取我们要用的数据，而不是全取，因为当我们select时，会增加web服务器的负担，增加网络传输的负载，查询速度自然就下降 。
三、EXPLAIN SELECT
对于这个功能估计很多人都没见过，但是这里强烈推荐使用。explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。主要用发就是在select前加上explain即可。
EXPLAIN SELECT [查找字段名] FROM tab_name ...
四、开启查询缓存
先见AI
数据为基，先见未见
95 查看详情
大多数的MySQL服务器都开启了查询缓存。这是提高性最有效的方法之一，而且这是被MySQL的数据库引擎处理的。当有很多相同的查询被执行了多次的时候，这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不用操作表而直接访问缓存结果了。
第一步把query_cache_type设置为ON，然后查询系统变量have_query_cache是否可用：
show variables like 'have_query_cache'
之后，分配内存大小给查询缓存，控制缓存查询结果的最大值。相关操作在配置文件中进行修改。
五、使用NOT NULL
很多表都包含可为 NULL （空值） 的列，即使应用程序井不需要保存 NULL 也是如此 ，这是因为可为 NULL 是列的默认属性。通常情况下最好指定列为 NOT NULL，除非真 的需要存储 NULL 值。
如果查询中包含可为 NULL 的列，对 MySQL 来说更难优化 ，因为可为 NULL 的列使 得索引、索引统计和值比较都更复杂 。可为NULL 的列会使用更多的存储空间 ，在 MySQL 里也需要特殊处理 。当可为NULL 的列被索引肘，每个索引记录需要一个额 外的字节，在 MyISAM 里甚至还可能导致固定大小 的索引 （例如只有一个整数列的 索引） 变成可变大小的索引。
通常把可为 NULL 的列改为 NOT NULL 带来的性能提升比较小 ，所以 （调优时） 没有 必要首先在现有schema中查找井修改掉这种情况 ，除非确定这会导致问题。但是， 如果计划在列上建索引 ，就应该尽量避免设计成可为 NULL 的列。当然也有例外 ，例如值得一提的是，InnoDB 使用单独的位 （bit ） 存储 NULL 值 ，所 以对于稀疏数据由有很好的空间效率 。但这一点不适用于MyISAM 。
六、存储引擎的选择
对于如何选择MyISAM和InnoDB,如果你需要事务处理或是外键，那么InnoDB可能是比较好的方式。如果你需要全文索引，那么通常来说MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从InnoDB中获得全文索引。
数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要
几个小时甚至几天来干这些事，InnoDB只需要几分钟。
您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM表中会非常快，而在InnoDB表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts语句在MyISAM下会快一些，但是updates在InnoDB 下会更快一些——尤其在并发量大的时候。
所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM也许会更适合。当然，在大型的环境下使用MyISAM也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方式。但需要记住InnoDB的表需要更多的内存和存储，转换100GB的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。
七、避免在 where 子句中使用 or 来连接
如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or Name = 'admin'
可以这样查询：
select id from t where num = 10union allselect id from t where Name = 'admin'
八、多使用varchar/nvarchar
使用varchar/nvarchar代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
九、避免大数据量返回
这里要考虑使用limit，来限制返回的数据量，如果每次返回大量自己不需要的数据，也会降低查询速度。
十、where子句优化
where 子句中使用参数，会导致全表扫描,因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。
应尽量避免在 where 子句中对字段进行表达式操作，避免在where子句中对字段进行函数操作这将导致引擎放弃使用索引而进行全表扫描。不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
以上就是分享mysql数据库常见的优化操作的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/414141.html
微信扫一扫 
支付宝扫一扫 
