mysql优化方法陈列

高并发大多的瓶颈在后台,在存储,mysql的正常的优化方案如下:

1)代码中sql语句优化

2)数据库字段优化,索引优化

3)加缓存,redis/memcache等

4)主从,读写分离

5)分区表

6)垂直拆分,解耦模块

7)水平切分

点评:

1、1&2是最简单,也是提升效率最快的方式。也许有人说这两点你已经做的很好了,你的每条语句都命中了索引,是最高效的。但是你是否是为了你的sql达到最优而去建索引,而不是从整个业务上来考虑。比如,订单表上我需要增加xx索引满足某单一业务,是否就一定要加,其他方法能否解决。如果要满足所有业务的需求,那么索引就泛滥了,对于千万级以上的表来说,维护索引的成本大大增加,反而增加了数据库的内存的开销。

2、数据库字段的优化。曾经发现一高级程序员在表字段的设计上,一个日期类型,被设计为varchar类型,不规范的同时,无法对写入数据校验,做索引的效率也有差别(网(xian)友(pen)的(liao)观(zai)点(shuo),具体差别原理不详)。

3、缓存适合读多写少更新频度相对较低的业务场景,否则缓存异议不大,命中率不高。缓存通常来说主要为了提高接口处理速度,降低并发带来的db压力以及由此产生的其他问题。你的接口时延多少?有没有被用户吐槽?有没有必要提升?好吧,我们的前台后台商家并发量太低,当我没说。

4、分区不是分表,结果还是一张表,只不过把存放的数据文件分词了多个小块,分块后。在表数据非常大的情况下,可以解决无法一次载入内存,以及大表数据维护等问题。

5、垂直拆分将表按列拆成多表,常见于将主表的扩展数据独立开,文本数据独立开,降低磁盘io的压力。

6、水平拆,这是一把最有效的牛刀。但是存在一个误区,有的人会觉得,为什么不在最开始就直接水平线拆,免去了后面迁移数据的麻烦。我个人感觉是,下定某个决策之前,必须有一个非常充分的理由。水平拆分的主要目的是提升单表并发读写能力(压力分散到各个分表中)和磁盘IO性能(一个非常大的.MYD文件分摊到各个小表的.MYD文件中)。如果没有千万级以上数据,为什么要拆,仅对单表做做优化也是可以的;再如果没有太大的并发量,分区表也一般能够满足。所以,一般情况下,水平拆分是最后的选择,在设计时还是需要一步一步走。

————————————————
版权声明:本文为CSDN博主「qiuweihong」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qiuweihong/article/details/78751466

原文地址:https://www.cnblogs.com/betterquan/p/11415681.html

时间: 2024-11-17 11:57:58

mysql优化方法陈列的相关文章

MySql优化方法---网上资料整理记录

1. 为查询缓存优化你的查询 大多数的MySQL服务器都开启了查询缓存.这是提高性最有效的方法之一,而且这是被MySQL的数据库引擎处理的.当有很多相同的查询被执行了多次的时候,这些查询结果会被放到一个缓存中,这样,后续的相同的查询就不用操作表而直接访问缓存结果了. 2. EXPLAIN 你的 SELECT 查询 使用 EXPLAIN 关键字可以让你知道MySQL是如何处理你的SQL语句的.这可以帮你分析你的查询语句或是表结构的性能瓶颈. EXPLAIN 的查询结果还会告诉你你的索引主键被如何利

mysql 优化方法

1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快.因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小.例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了.同样的,如果可以的话,我们应该使用MEDIUMINT而不是 BIGIN来定义整型字段. 另外一个提高效率的方法

mysql优化方法

1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快.因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小.例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了.同样的,如果可以的话,我们应该使用MEDIUMINT而不是 BIGIN来定义整型字段.  另外一个提高效率的方

最全 MySQL 优化方法,从此优化不再难

说起MySQL的查询优化,相信大家收藏了一堆奇技淫巧:不能使用SELECT *.不使用NULL字段.合理创建索引.为字段选择合适的数据类型..... 你是否真的理解这些优化技巧?是否理解其背后的工作原理?在实际场景下性能真有提升吗?我想未必.因而理解这些优化建议背后的原理就尤为重要,希望本文能让你重新审视这些优化建议,并在实际业务场景下合理的运用. MySQL逻辑架构 如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器.下图展示了MySQL的逻辑架构图

30多条mysql数据库优化方法,千万级数据库记录查询轻松解决【转】

转自:http://www.ihref.com/read-16422.html 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描, Sql 代码 : select id from t where num is null; 可以在 num 上设置默认值 0,确保表中 num 列没有 null 值,然后这样查询: Sql 代码 : s

数据库调优教程(十三) MySQL数据库其他优化方法

六.           MySQL数据库其他优化方法 最后一章,谈谈前面没有涉及的一些优化方法. 1.      My.ini配置文件 这里只介绍两个最重要的,其他的不过多介绍. 1)    配置 最大连接数 默认为100,建议设为1000 2)   配置 缓存 在my.ini的[mysqld]节点开启查询缓存,配置如下 query_cache_size = 268435456 query_cache_type = 1 query_cache_limit = 1048576 2.      使

mysql limit分页优化方法分享

MySQL的优化是非常重要的.其他最常用也最需要优化的就是limit.MySQL的limit给分页带来了极大的方便,但数据量一大的时候,limit的性能就急剧下降. 同样是取10条数据 select * from yanxue8_visit limit 10000,10 和 select * from yanxue8_visit limit 0,10 就不是一个数量级别的. 网上也很多关于limit的五条优化准则,都是翻译自MySQL手册,虽然正确但不实用.今天发现一篇文章写了些关于limit优

转载:30多条mysql数据库优化方法,千万级数据库记录查询轻松解决

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描, Sql 代码 : select id from t where num is null; 可以在 num 上设置默认值 0,确保表中 num 列没有 null 值,然后这样查询: Sql 代码 : select id from t where num=0; 3.应尽量避免在 wh

redmine在linux上的mysql性能优化方法与问题排查方案

iredmine的linux服务器mysql性能优化方法与问题排查方案 问题定位: 客户端工具: 1. 浏览器inspect-tool的network timing工具分析 2. 浏览器查看 response header, 分析http server 与 web server.       服务器工具:   0. nmon 查看各类系统负载, rrdtool 查看网络状况.   1. uptime看cpu负载;    free看内存;  mem ; cat /proc/meminfo以及  i