精华内容
下载资源
问答
  • MYSQL数据库优化方向sql及索引优化,存储优化(程序)数据库表结构优化系统配置硬件一、SQL语句优化1、Mysql慢查日志的开启和日志存储格式查看慢查询日志是否开启:show variables like 'slow_query_log'查看没索引...

    MYSQL数据库优化方向

    sql及索引优化,存储优化(程序)

    数据库表结构优化

    系统配置

    硬件

    一、SQL语句优化

    1、Mysql慢查日志的开启和日志存储格式

    查看慢查询日志是否开启:show variables like 'slow_query_log'

    查看没索引日志是否记录:show variables like '%log%'

    列表项‘log_queries_not_using_indexes’,如果是OFF

    开启非索引日志记录:set global log_queries_not_using_indexes=on

    查询时间设置(超过多长时间的sql记录慢查询日志):show variables like 'long_query_time';

    这里测试设置为空0:set global long_query_time=0.0  (需要重新链接下mysql才回看到设置的值)

    测试:随便查询几个表

    找到慢查询日志存放目录:show varibels like '%log%';

    | slow_query_log_file                     | /var/lib/mysql/ubuntu-slow.log

    退出mysql,

    sudo cat /var/lib/mysql/ubuntu-slow.log ,查看慢查日记记录内容

    519ee2848d02245ea620b257a118f494.png

    2、慢查询日志管理工具

    mysqldumpslow

    退出mysql,系统中:mysqldumpslow -h查看工具使用方法,比如:

    sudo mysqldumpslow -t 5 /var/lib/mysql/ubuntu-slow.log

    pt-query-digest功能比mysqldumpslow强的多

    查看帮助命令:pt-query-digest --help

    使用实例:sudo pt-query-digest /var/lib/mysql/ubuntu-slow.log

    3、慢查询日志如何发现有问题的sql

    744a55437e9f6e469e8f594c7490aa2e.png

    rows examine扫描行数。

    4、explain查询和分析sql执行计划,先计划在执行

    5b5e62aeababd65cde334d936fa0ad17.png

    a0127225eb8c850df2c153796fe42442.png

    using filesort 和using temporary一般是order by 和group by导致的。

    5、max()优化

    max()直接使用会扫描所有行,创建索引后不需要扫描:

    stelin-2144804

    创建索引:explain select max(payment_date) from payment \G;

    命::explain select max(payment_date) from payment \G;

    6、子查询优化

    优化成 join..on(链接方式,若果一对多,注意重复数据处理ditinct)

    7、group by优化

    sql:EXPLAIN SELECT actor.first_name,actor.last_name,COUNT(*) FROM film_actor INNER JOIN actor USING(actor_id) GROUP BY film_actor.actor_id;

    操作了大量的io(filesort)

    优化成子查询:

    EXPLAIN SELECT actor.first_name,actor.last_name,c.cnt FROM actor INNER JOIN (SELECT film_actor.actor_id,COUNT(*) AS cnt FROM film_actor GROUP BY actor_id) AS c USING(actor_id);

    group 多表链接尽量使用子查询。

    8、limit优化

    普通sql:EXPLAIN SELECT f.film_id,f.description,f.title FROM film f LIMIT 0,5;扫描全表,type是all

    第一步优化:EXPLAIN SELECT f.film_id,f.description,f.title FROM film f ORDER BY f.film_id LIMIT 0,5;

    通过一个ID排序,也是扫描全表但是,type是index(索引类型)

    第二步优化:EXPLAIN SELECT f.film_id,f.description,f.title FROM film f WHERE film_id<=56 AND       film_id>50 ORDER BY f.film_id LIMIT 0,5;

    通过记录上次id位置,避免扫描全表,注意适用于ID递增,没有空缺的表。

    二、索引优化

    1、选择合适的列建立索引

    e28be9d0673c60e994694c966dd4c9b4.png

    列的离散度,是指列的唯一性。离散度越大,唯一性越大。比如:SELECT COUNT(DISTINCT p.customer_id), COUNT(DISTINCT p.staff_id) FROM payment AS p,统计的customer_id,比staff_id大,说明,离散密度就大。

    2、SQL优化索引

    32733f3292c8d6a90762022c80dc61dc.png

    e65c50451aa7aeb05728adb2478df42b.png

    78b49521ac1f8ec7a250e38bb0853b84.png

    优化重复和冗余的索引。此工具可以显示重复和冗余的索引,以及解决办法。

    3、索引维护(删除不用的索引)

    3e4f8d8e74f73381fc63612d345feaa3.png

    三、数据化结构优化

    1、选择合适的数据类型

    08c97d7acd07c2f476c680aece1c0679.png

    39df9b81cc867338e3739a6a209d22c2.png

    f454a00725865847e65cb619a78f6e2d.png

    2、范式化优化

    4ba764dfe0de9936870a2263337a188e.png

    f6fb3b1f1d5221338eb81031e902d477.png

    比如删除表里面所有饮料的商品,结果饮料分类和描述也删除了。

    3、反范式化优化

    4891d0fa25ff83be4b0737b03dc6c454.png

    d6aa35fa2f80963c9a763026641f18e8.png

    7e8582503e2e879f2493d6966873b511.png

    a0b26d7d80a9db48ae5b2cb6cb34d400.png

    b8c43ea85082878148f574e05a7542ab.png

    4、表垂直拆分

    cd632f5f293eb369aefe4b33bface6b8.png

    062fe549487fb8fb975428b774acd5be.png

    45ab9dca99eda32dcd078b1a57c77125.png

    b66fa91d98b9e25067b1fb9fce5e8c5a.png

    5、表的水平拆分

    3948d13adc7e593f2bed7d6d8712eee9.png

    d8b067b1db8985ce42accf6d1fae444e.png

    四、系统配置优化

    1、数据库操作系统配置的优化

    45031b8384d36c5b0d3597ee93bc01d1.png

    562edc812629772aa9ba657c1dc0a41c.png

    2、mysql常用配置参数

    292285198888883855fbbbaa178fd564.png

    0c001fb38d336bd920fe3d6fb8f1aa15.png

    93f112c49a6f21cc2498cae158884f76.png

    dbe7497f6745437a2284d3a19dfa23d1.png

    b41892767cf54675e1a4d283e7ae057c.png

    efbdb38adffbd63c5ce2534826f7f5fc.png

    4d996c3c2570227f4793a64e3fc58d82.png

    五、服务器硬件优化

    1、CPU的选择

    161911a23b85633d3b081a431ef6dc97.png

    通常选择单核更快的CPU

    2、磁盘的选择

    49db7f87e27f49a05af0ad523c5ab94e.png

    RAID0,读写最好,RAIA1,数据不会丢失,安全性高。通常选择RAID1+0

    84420885c8951eb62f85dd2fc5ac927e.png

    68e1534462e736eff8c9cab8679bc378.png

    大小: 104.2 KB

    85624252ddc8f90aba0bec93e8a0b421.png

    大小: 102.3 KB

    145bdf77ed1a3f4aa205e02dd6ec4c86.png

    大小: 146.8 KB

    90d81708fdce7ab4e1f4a53fe428538b.png

    大小: 104.1 KB

    98c61be06d033e12ccb565bccdb87380.png

    大小: 132.1 KB

    d9761901aff7513c03cda5880eaba319.png

    大小: 85.5 KB

    784e5510bf640d2901aef4976e3651e8.png

    大小: 90.2 KB

    42c9c8fc03d29b78635175f1e8dbf9a6.png

    大小: 57 KB

    26c65563d2f7ccea0c6680d64db0aa35.png

    大小: 94.3 KB

    ca15526519efe95e731dd0c4664c4582.png

    大小: 90.9 KB

    443c14e239bdbbd5ccff06886d25c261.png

    大小: 97.3 KB

    73a9352a388a37e339c8796e7810799c.png

    大小: 99 KB

    ea1784d54fe401c7cd8904907602a5a4.png

    大小: 174.2 KB

    d07e490801427a4e90b8182ee5141014.png

    大小: 60.8 KB

    a697a1e097338580600844a36b7c02c6.png

    大小: 134.5 KB

    d9d707f887c441ee76ff80f78a61b160.png

    大小: 124.9 KB

    e12c7ccc309cfb0d276a95ff37fd9eed.png

    大小: 90.6 KB

    0deaa1c03d39e40e5b9f4980828433d5.png

    大小: 146.7 KB

    929ca7486a28e67aa84f9b2cd7609d39.png

    大小: 49.1 KB

    52fb33a6a7b42c61adb1cedfe2ad267f.png

    大小: 146.7 KB

    cf2bdf07993d532643bd308b0f7226f2.png

    大小: 49.1 KB

    aee94630a468fb46e107860ee4705e86.png

    大小: 139 KB

    e520ae2719dc6ad5e2a23f57181621f7.png

    大小: 132.2 KB

    472308c6663f19225855286cb8d21cf3.png

    大小: 45.1 KB

    4f5c6bd8408e47df17c1872fd48e688d.png

    大小: 75.3 KB

    25b18fb5663984f1f4d823281223889b.png

    大小: 117.1 KB

    e415b02679f7aadd7fec20c4856abb70.png

    大小: 67.2 KB

    217d10bc45d554e6a144f94d77ccffe8.png

    大小: 122.7 KB

    e5923a631117d1a0a9ab0881a0776acd.png

    大小: 139.2 KB

    4e01c1c835e8244fbae2c465de4a8c2c.png

    大小: 130.6 KB

    5b600fba3cf6737d66f8174c8050fe25.png

    大小: 31.7 KB

    bdff7d2a77bee11d4b5c1e28c187b439.png

    大小: 27.7 KB

    ac9488a7685411efaf8496cad47d9931.png

    大小: 46.6 KB

    dfa47021ca2c572b5c1e2d4e39a1b5c1.png

    大小: 29.4 KB

    8c5ef9dcbc3e21e622df9e14bfdd5d97.png

    大小: 39.3 KB

    30b56d0723f5f8c6ca1fa1d8c9a7b85d.png

    大小: 24.3 KB

    bcd99c403057ff376c3707104bc4001e.png

    大小: 80.3 KB

    b61e9d0916b6e168fe101b3608737da4.png

    大小: 44.9 KB

    bce2eafff3e9f1ab98e3b4295fc7b87e.png

    大小: 166.3 KB

    分享到:

    18e900b8666ce6f233d25ec02f95ee59.png

    72dd548719f0ace4d5f9bca64e1d7715.png

    2014-10-17 17:47

    浏览 545

    分类:数据库

    评论

    展开全文
  • 前言数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.1. 优化一览图2. 优化...

    前言

    数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.

    1. 优化一览图

    2. 优化

    笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.

    2.1 软优化

    2.1.1 查询语句优化

    1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.

    2.例:

    DESC SELECT * FROM `user`

    显示:

    其中会显示索引和查询数据读取数据条数等信息.

    2.1.2 优化子查询

    在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.

    2.1.3 使用索引

    索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者一文,介绍比较详细,此处记录使用索引的三大注意事项:LIKE关键字匹配'%'开头的字符串,不会使用索引.

    OR关键字的两个字段必须都是用了索引,该查询才会使用索引.

    使用多列索引必须满足最左匹配.

    2.1.4 分解表

    对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,

    2.1.5 中间表

    对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.

    2.1.6 增加冗余字段

    类似于创建中间表,增加冗余也是为了减少连接查询.

    2.1.7 分析表,检查表,优化表

    分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.

    1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;

    Op:表示执行的操作.

    Msg_type:信息类型,有status,info,note,warning,error.

    Msg_text:显示信息.

    2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]

    option 只对MyISAM有效,共五个参数值:QUICK:不扫描行,不检查错误的连接.

    FAST:只检查没有正确关闭的表.

    CHANGED:只检查上次检查后被更改的表和没被正确关闭的表.

    MEDIUM:扫描行,以验证被删除的连接是有效的,也可以计算各行关键字校验和.

    EXTENDED:最全面的的检查,对每行关键字全面查找.

    3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

    LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.

    2.2 硬优化

    2.2.1 硬件三件套配置多核心和频率高的cpu,多核心可以执行多个线程.

    配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.

    配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.

    2.2.2 优化数据库参数

    优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.key_buffer_size:索引缓冲区大小

    table_cache:能同时打开表的个数

    query_cache_size和query_cache_type:前者是查询缓冲区大小,后者是前面参数的开关,0表示不使用缓冲区,1表示使用缓冲区,但可以在查询中使用SQL_NO_CACHE表示不要使用缓冲区,2表示在查询中明确指出使用缓冲区才用缓冲区,即SQL_CACHE.

    sort_buffer_size:排序缓冲区

    更多参数传送门:

    2.2.3 分库分表

    因为数据库压力过大,首先一个问题就是高峰期系统性能可能会降低,因为数据库负载过高对性能会有影响。另外一个,压力过大把你的数据库给搞挂了怎么办?

    所以此时你必须得对系统做分库分表 + 读写分离,也就是把一个库拆分为多个库,部署在多个数据库服务上,这时作为主库承载写入请求。然后每个主库都挂载至少一个从库,由从库来承载读请求。

    2.2.4 缓存集群

    如果用户量越来越大,此时你可以不停的加机器,比如说系统层面不停加机器,就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高,就扩容加数据库服务器,通过分库分表是可以支持扩容机器的,如果数据库层面的读并发越来越高,就扩容加更多的从库。

    但是这里有一个很大的问题:数据库其实本身不是用来承载高并发请求的,所以通常来说,数据库单机每秒承载的并发就在几千的数量级,而且数据库使用的机器都是比较高配置,比较昂贵的机器,成本很高。如果你就是简单的不停的加机器,其实是不对的。所以在高并发架构里通常都有缓存这个环节,缓存系统的设计就是为了承载高并发而生。

    所以单机承载的并发量都在每秒几万,甚至每秒数十万,对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性,对那种写少读多的请求,引入缓存集群。

    具体来说,就是在写数据库的时候同时写一份数据到缓存集群里,然后用缓存集群来承载大部分的读请求。这样的话,通过缓存集群,就可以用更少的机器资源承载更高的并发。

    结语

    一个完整而复杂的高并发系统架构中,一定会包含:各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.

    推荐阅读(点击即可跳转阅读)

    2.面试题内容聚合​mp.weixin.qq.com

    展开全文
  • 前言数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.1. 优化一览图2. 优化...

    前言

    数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.

    1. 优化一览图

    2. 优化

    笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.

    2.1 软优化

    2.1.1 查询语句优化

    1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.

    2.例:DESC SELECT * FROM `user`

    显示:

    其中会显示索引和查询数据读取数据条数等信息.

    2.1.2 优化子查询

    在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.

    2.1.3 使用索引

    索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者一文,介绍比较详细,此处记录使用索引的三大注意事项:LIKE关键字匹配%开头的字符串,不会使用索引.

    OR关键字的两个字段必须都是用了索引,该查询才会使用索引.

    使用多列索引必须满足最左匹配.

    2.1.4 分解表

    对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,

    2.1.5 中间表

    对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.

    2.1.6 增加冗余字段

    类似于创建中间表,增加冗余也是为了减少连接查询.

    2.1.7 分析表,,检查表,优化表

    分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.

    1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;

    Op:表示执行的操作.

    Msg_type:信息类型,有status,info,note,warning,error.

    Msg_text:显示信息.

    2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]

    option 只对MyISAM有效,共五个参数值:QUICK:不扫描行,不检查错误的连接.

    FAST:只检查没有正确关闭的表.

    CHANGED:只检查上次检查后被更改的表和没被正确关闭的表.

    MEDIUM:扫描行,以验证被删除的连接是有效的,也可以计算各行关键字校验和.

    EXTENDED:最全面的的检查,对每行关键字全面查找.

    3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

    LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.

    2.2 硬优化

    2.2.1 硬件三件套

    1.配置多核心和频率高的cpu,多核心可以执行多个线程.

    2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.

    3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.

    2.2.2 优化数据库参数

    优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.key_buffer_size:索引缓冲区大小

    table_cache:能同时打开表的个数

    query_cache_size和query_cache_type:前者是查询缓冲区大小,后者是前面参数的开关,0表示不使用缓冲区,1表示使用缓冲区,但可以在查询中使用SQL_NO_CACHE表示不要使用缓冲区,2表示在查询中明确指出使用缓冲区才用缓冲区,即SQL_CACHE.

    sort_buffer_size:排序缓冲区

    2.2.3 分库分表

    因为数据库压力过大,首先一个问题就是高峰期系统性能可能会降低,因为数据库负载过高对性能会有影响。另外一个,压力过大把你的数据库给搞挂了怎么办?所以此时你必须得对系统做分库分表 + 读写分离,也就是把一个库拆分为多个库,部署在多个数据库服务上,这时作为主库承载写入请求。然后每个主库都挂载至少一个从库,由从库来承载读请求。

    2.2.4 缓存集群

    如果用户量越来越大,此时你可以不停的加机器,比如说系统层面不停加机器,就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高,就扩容加数据库服务器,通过分库分表是可以支持扩容机器的,如果数据库层面的读并发越来越高,就扩容加更多的从库。但是这里有一个很大的问题:数据库其实本身不是用来承载高并发请求的,所以通常来说,数据库单机每秒承载的并发就在几千的数量级,而且数据库使用的机器都是比较高配置,比较昂贵的机器,成本很高。如果你就是简单的不停的加机器,其实是不对的。所以在高并发架构里通常都有缓存这个环节,缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万,甚至每秒数十万,对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性,对那种写少读多的请求,引入缓存集群。具体来说,就是在写数据库的时候同时写一份数据到缓存集群里,然后用缓存集群来承载大部分的读请求。这样的话,通过缓存集群,就可以用更少的机器资源承载更高的并发。

    结语

    一个完整而复杂的高并发系统架构中,一定会包含:各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.

    展开全文
  • MySQL数据库优化

    2021-02-05 23:55:28
    数据库优化的目的1.避免出现页面访问错误由于数据库连接 timeout 产生页面5xx错误由于慢查询造成页面无法加载由于阻塞造成数据无法提交2.增加数据库的稳定性很多数据库问题都是由低效的查询引起的3.优化用户体验流畅...

    数据库优化的目的

    1.避免出现页面访问错误

    由于数据库连接 timeout 产生页面5xx错误

    由于慢查询造成页面无法加载

    由于阻塞造成数据无法提交

    2.增加数据库的稳定性

    很多数据库问题都是由低效的查询引起的

    3.优化用户体验

    流畅的页面访问速度

    良好的网站功能体验

    MySQL数据库优化

    24bb441d701f3c2be705f98381925cdd.png

    上图是数据库优化的金字塔结构。可以看出,SQL及索引优化位于金字塔的最低层,是数据库优化的基础,成本最低,效果却最好。

    一 SQL语句优化

    找出有问题的SQL

    1.1 使用MySQL慢查询日志对低效率的SQL进行监控

    1)查询是否开启了慢查询日志

    show variables like 'slow_query_log';

    2)设置记录未使用索引的查询

    set global log_queries_not_using_indexes=on;

    3)设置慢查询时间

    set global long_query_time=0.1;

    注:直接修改 global 的 long_query_time 在当前窗口是不生效的,在新打开的窗口才有效果。如果想让当前窗口生效,在设置时不用加 global 关键字。

    4)设置慢查询日志地址

    set global slow_query_log_file='/home/log/mysql/mysql-query.log';

    5)开启慢查询日志

    set global slow_query_log=on;

    开启之后,就会在之前设置的 slow_query_log_file 文件中看到慢查询日志。

    1.2 慢查询日志的格式

    1)SQL的执行时间

    # Time: 140712 8:32:58

    2)执行SQL的主机信息

    # User@Host: root[root] @ localhost []

    3)SQL的执行信息(如:执行时间、锁定时间、发送行数、扫描行数)

    # Query_time: 0.000282 Lock_time: 0.000092 Rows_sent: 3 Rows_examined: 3SET timestamp=1405125199;

    4)SQL的内容

    select * from store limit 10;

    1.3 MySQL慢查日志分析工具之 mysqldumpslow

    mysqldumpslow 是MySQL官方自带的工具,可以满足平时简单统计。

    查看使用帮助:

    mysqldumpslow -h

    用法:

    mysqldumpslow 参数 日志文件路径

    比如:想要得到按照发送行数排序的前3条数据

    mysqldumpslow -t 3 -s r /home/log/mysql/mysql-query.log

    mysqldumpslow 的不足之处:统计结果的信息不多,无法满足SQL优化的需要。

    1.4 MySQL慢查日志分析工具之 pt-query-digest

    pt-query-digest 是 Percona Toolkit 工具中的一个。需要自行安装 Percona Toolkit,再使用 pt-query-digest。

    pt-query-digest 用法实例:

    1)直接分析慢查询文件,并将分析结果存储到 slow.log:

    pt-query-digest mysql-query.log > slow.log

    2)分析指定范围内的查询:

    pt-query-digest mysql-query.log --since '2017-05-28 23:28:00' --until '2017-05-28 23:59:59' > slow.log

    3)分析含有 select 语句的慢查询:

    pt-query-digest --filter '$event->{fingerprint} =~ m/^select/i' mysql-query.log > slow.log

    4)分析所有的全表扫描或者 full join 的慢查询

    pt-query-digest --filter '(($event->{Full_scan} || "") eq "yes") || (($event->{Full_join} || "") eq "yes")' mysql-query.log > slow.log

    5)把分析结果保存到 query_review 表

    pt-query-digest --user=root --password=123456 --review h=localhost,D=test,t=query_review --create-review-table slow.log

    建议:当 mysql_query.log 很大时,最好还是将慢查询日志移到其他机器进行分析。使用 pt-query-digest 分析,比较耗费本地主机的资源。

    1.5 根据慢查询日志的分析结果,找出有问题的SQL

    1)查询次数多且每次查询占用时间长的SQL

    通常为 pt-query-digest 分析的前几个查询

    2)IO大的SQL

    注意 pt-query-digest 分析中的 Rows examine 项

    3)未命中索引的SQL

    注意 pt-query-digest 分析中 Rows examine 和 Rows send 的对比

    1.6 使用 explain 查询和分析 SQL 的执行计划

    explain 返回结果中各列的含义

    table:显示这一行的数据是关于哪张表的

    type:显示连接使用了哪种类型,从最好到最差的连接类型为 const、eq_reg、ref、range、index 和 all

    possible_keys:显示可能应用在这张表中的索引。显示为空,则没有可能的索引

    key:实际使用的索引。如果为 NULL,则没有使用索引

    key_len:使用的索引的长度。在不损失精确性的情况下,长度越短越好

    ref:显示索引的哪一列被使用了。如果可能的话,是一个常数

    rows:MySQL认为必须检查的用来返回请求数据的行数

    extra:显示 MySQL 在查询过程中的一些详细信息。若是 Using filesort 或者 Using temporary,就需要进行查询优化了

    展开全文
  • 数据库优化有哪些? 分别需要注意什么 对操作系统、存储硬件网络、数据库原理等方面有比较扎实的基础知识,另一方面是需要花大量时间对特定的数据库进行实践测试与总结。 非常了解我们SQL的业务逻辑,我们清楚SQL中...
  • 来源:segmentfault.com/a/1190000018631870前言数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让...
  • oracle数据库优化pdf

    2021-05-01 08:02:20
    oracle数据库优化pdf通过图文结合的形式为oracle程序使用者提供了详细透彻的使用说明指导服务。oracle数据库软件主要为开发人员提供测试、伸展等服务,首次接触oracle数据库程序的朋友可以来ttyx8下载小编提供的免费...
  • 本文简单讲述了PHP数据库编程之MySQL优化策略。分享给大家供大家参考,具体如下:前些天看到一篇文章说到PHP的瓶颈很多情况下不在PHP自身,而在于数据库。我们都知道,PHP开发中,数据的增删改查是核心。为了提升PHP...
  • mysql数据库优化

    2021-01-27 08:04:21
    优化方向:sql优化1.数据库慢查询日志首先开启数据库的慢查询在MySQL配置文件my.cnf中修改配置文件方式:注意:修改以下参数,需要重新启动数据库服务才会生效。slow_query_log=off|on --是否开启慢查询日志slow_...
  • 数据库优化确实是比较重要的板块,也是面试数据开发岗位几乎必考的面试题。 本菜鸡这学期学了一门数据库相关课《Data Storing and Retrieving》,字面意思理解也就是说最重要的两大板块:一是数据存储,二是数据...
  • 这里简单的讲一下:如何使用数据库引擎优化顾问优化数据库简单的优化一下数据库。一、启动 microsoft sql server management studio(就是sql的管理工具)二、工具->sql server profiler三、s...
  • 我们都知道 WordPress 使用的数据库是 MySQL 这个世界上使用最广的开源数据库(当然也可以简单的 hack 换成其他数据库),WordPress 把所有的信息,如日志,留言,当前主题,使用的插件等等,都放在 MySQL 数据库中,...
  • 顺分面试题:你都用过哪些数据库,数据库优化操作回答:1、根据服务层面配置mysql性能优化参数;2、从系统层面增强mysql的性能:优化数据表结构① 将字段较多的表分解成多个表对于字段较多的表,如果有些字段的使用...
  • 减少 IO 次数IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。...
  • 本篇文章给大家带来的内容是关于MySQL数据库优化的介绍(图文),有一定的参考价值,有需要的朋友可以参考一下,希望对你有所帮助。数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的...
  • 查询优化规则: 首先拿到关系代数式子 写成语法树形式 可以下移的选择往下移到底 把不需要的列投影去掉 分组:一个笛卡尔积(二元运算)分为一组 例题1:
  • 一、数据库占用的空间大小、表占用空间大小、索引占用空间大小在用阿里云的数据库的时候经常出现磁盘空间爆满的情况。所以要经常查询数据库相关内容占用的磁盘大小,有很多mysql客户端如navicat 就可以直接查看...
  • 1、Sql优化主要优化的还是查询, 优化查询的话, 索引优化是最有效的方案。 首先要根据需求写出结构良好的SQL,然后根据SQL 在表中建立有效的索引。但是如果索引太多,不但会影响写入的效率,对查询也有一定的影响...
  • 2:按文件中记录数量切换日志文件, 日志记录为详细模式; 3:不切换日志文件,日志记录为简单模式,只记录时间和原始语句 5. 设置临时表空间大小 cat /home/dmdba/dmdbms/data/DAMENG/dm.ini |grep TEMP TEMP_SIZE...
  • 本文将全面讲解Mysql的性能优化,包括数据查询优化数据库结构优化、插入数据优化、服务器优化等,一文学会MySQL全部常用的优化策略。 一篇新手直接拿来即用的MySQL优化教程。
  • 数据库优化相关

    2021-04-26 10:54:58
    一、为什么要分库分表? 减小数据库的负担,提高数据库的效率,缩短查询时间...三、数据库优化 从硬件方面来说,比如 CPU,内存,磁盘,网络等等,我们可以通过提高硬件,来解决这个问题。但是带来的收益和成本投入比例
  • 分库分表是为了解决由于数据量过大而导致数据库性能降低问题的技术,将原来独立的数据库拆分成若干个数据库,将数据量比较大的表拆分成若干个数据表,使得单一数据库、单一数据表的数据量变小,从而达到提升数据库...
  • 背景“那啥,你过来一下!”“怎么了?我代码都单元测试了的,没出问题啊!”我一脸懵逼跑到运维大佬旁边。...那个,能不能看下数据库监控日志...”运维大佬又数落了我几句,然后调开了数据库监控日志。那家伙...
  • 关于面试面试我还通过一些渠道整理了需要大厂真实面试主要有:蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初,中级,高级Java面试题集合,附带超详细答案...
  • 本文为性能优化的第一篇——数据库性能优化,原理适用于大部分数据库包括Sqlite、Mysql、Oracle、Sql server,详细介绍了索引(优缺点、分类、场景、规则)和事务,最后介绍了部分单独针对Sqlite的优化。目前性能优化...
  • 数据库优化-话题 为什么要优化? 系统的吞吐量瓶颈往往出现在数据库的访问速度上 数据库中的数据越来越多,处理时间会相应变慢 优化原则:减少资源占用,增加系统的反应速度 0.Redis缓存 减少数据库连接是一种优化...
  • 对于复杂的多表 Join,一方面由于其优化器受限,再者在Join 这方面所下的功夫还不够,所以性能表现离 Oracle等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 242,052
精华内容 96,820
关键字:

数据库优化详细