数据库优化思路与方向

一、基础优化

mysql> show status like 'valus'

connections //链接参数

uptime //上线时间

slow_queries //慢查询次数

com_select

com_insert

com_update

com_delete

二、优化查询:

mysql> explain select * from handb.fruits;

+----+-------------+--------+------+---------------+------+---------+------+------+-------+

| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows | Extra |

+----+-------------+--------+------+---------------+------+---------+------+------+-------+

|  1 | SIMPLE      | fruits | ALL  | NULL          | NULL | NULL    | NULL |    2 |       |

+----+-------------+--------+------+---------------+------+---------+------+------+-------+

table查询表的次数

possible_keys索引

key当前索引

key_len索引长度

ref一起查询的列或者常数

rows必要行数

Extra详细信息

三、索引对查询的影响

四、优化数据库结构

1、拆分旧表形成新表

2、增加中间表

五、插入优化

1、禁用索引

mysql> alter table book disable keys;

mysql> alter table book enable keys;

2、禁用唯一查询

mysql> set unique_checks=0 | 1 ;   //0关闭 1开启

3、禁用外键检查

mysql> set foreign_key_checks=0 |  1

4、禁用自动提交

mysql> set autocommit=0 | 1

六、分析检查优化表

mysql> analyze table fruits;

type:status 常态

info信息 //有重复信息

note注意 //有null空值

warning警告 //超过过慢查询时间

error错误 //表中有错误选项,不可用

七、检查表

mysql> check table fruits fast;

QUICK:不扫描。不检查错误的链接。

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

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

MEDIUM:扫描行,以验证被删除的链接是有效的,也可以计算各行的关键字效验和,并使用计算出的效验和验证这一点。

EXTENDED:对每行的所有附件自进行一个全面的关键字查找,这可以确保表示百分百一致的,但是花费时间较长。

八、mysql服务器优化

缓冲区:希望被更改的数据在内存中驻留的时间更长而产生,主要是保留脏页信息在内存中。不接受内存的管理,但是接受mysql程序的管理。

保证缓冲区大小:

[mysqld]

query_cache_size=512M

query_cache_type=1    //0表示不适用缓冲区。

1表示一旦开启,所有的查询都将使用缓冲区。如果不希望从缓冲区查询,需要在select语句后增加选项no_sql_cache,表示当前查询不适用缓冲区查询。

2表示,只有在查询的select是增加sql_cache才会从缓冲区查找。

key_buffer_size   //索引缓冲区大小。索引缓冲区的所有线程共享。他的大小取决于内存的大小。太大会导致频繁换页,也会降低系统性能。

table_cache //同时打开的表的个数。越大表示同时打开的表越多。太大影响系统性能。

sort_buffer_size //排序缓存大小,越大,表示排序速度越快。提高order by和group by的效率默认2M

read_buffer_size //每个表分配的缓冲区的大小。当线程连续扫描时,才会使用这个缓冲区。

read_md_buffer_size //每个线程保留的缓冲区的大小,与上面相似,但是用于特定顺序才会使用。如果出现连续扫描与读取,则调整该参数。set session read_md_buffer_size = n

innodb_buffer_pool_size //innodb和索引的最大缓存,越大查询越快

max_connections //表示数据库的最大连接数。主要浪费内存大小。(大于系统最大链接数,会死机)

innodb_flush_log_at_trx_commit //表示缓冲区数据什么时候写入到日志中,并且将日志写入到磁盘当中。该值有三个值:

0每隔一秒将数据写入日志,再写入硬盘。不安全,但是速度快

1每次提交事务的时候才写入日志,再写入硬盘。安全,但是速度慢

2每次提交事务的时候写入日志,每隔一秒写入硬盘。出现故障会丢失1-2s数据。

back_log //表示多少个请求可以存放在堆栈中。对TCP/IP的监听列队的大小。不接受新请求之前把数据放在缓存。只有希望一个短时间内有很多链接,才启用此值。操作系统的列队限制比mysql更大,不能超过,否则无效。

interactive_timeout //关闭服务器链接前的等待时间。

thread_buffer_size //每个需要排序的线程分配的缓冲区的大小,如果有很多新的线程,可以调高这个值。

wait_timeout //服务器关闭一个链接所等待的时间s,默认28800

原文地址:http://blog.51cto.com/wuhui1994/2060777

时间: 2024-11-04 19:40:34

数据库优化思路与方向的相关文章

数据库优化思路

数据库优化思路有如下几个方面: 1.建立索引 2.分库.分表.分区 3.数据库引擎 mysql比较常用的数据库引擎是:innodb .myisam     myisam查询效率比innodb快1-2倍,     myisam是表级锁,适用于一次插入多次查询的表,或者是读写分离中读库中的表     innodb是行级锁,适用于频繁更新,插入,读写分离写库中的表 详细可参考:https://www.cnblogs.com/0201zcr/p/5296843.html 4.预处理 实时数据放入缓存中

MySQL5.6.17学习笔记(一)数据库优化思路

欢迎访问:鲁春利的工作笔记,学习是一种信仰,让时间考验坚持的力量. 本文出自 "鲁春利的工作笔记" 博客,请务必保留此出处http://luchunli.blog.51cto.com/2368057/1705491

58沈剑:秒杀系统架构优化思路

有个兄弟分享秒杀系统的优化,其观点有些赞同,大部分观点却并不同意,结合自己的经验,谈谈自己的一些看法. 一.为什么难 秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如12306抢票,亦与秒杀类似,瞬时流量更甚. 二.常见架构 流量到了亿级别,常见站点架构如上: 1)浏览器端,最上层,会执行到一些JS代码 2)站点层,这一层会访问后端数据,拼html页面返回给浏览器 3)服务层,向上游屏

【58沈剑架构系列】秒杀系统架构优化思路

一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据: 3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 二

秒杀系统架构优化思路

[总结] 上文应该描述的非常清楚了,没什么总结了,对于秒杀系统,再次重复下我个人经验的两个架构优化思路: (1)尽量将请求拦截在系统上游(越上游越好): (2)读多写少的常用多使用缓存(缓存抗读压力): 浏览器和APP:做限速 站点层:按照uid做限速,做页面缓存 服务层:按照业务做写请求队列控制流量,做数据缓存 数据层:闲庭信步 并且:结合业务做优化 一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的

数据库优化举例详解

数据库优化举例详解 林涛 发表于:2016-3-16 1:01 分类:XSQL/程序/等 标签:mysql,mysql优化 112次 数据库是所有架构中不可缺少的一环,一旦数据库出现性能问题,那对整个系统都会来带灾难性的后果.并且数据库一旦出现问题,由于数据库天生有状态(分主从)带数据(一般还不小),所以出问题之后的恢复时间一般不太可控,所以,对数据库的优化是需要我们花费很多精力去做的. 硬件层优化 这一层最简单,最近几年相信大家对SSD这个名词并不陌生,其超高的IOPS在刚出现在大家视野中的时

阿里秒杀系统架构优化思路

秒杀业务为什么难做 im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息) 微博系统,每个人读你关注的人的数据,一个人读多个人的数据 秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 优化方向 优化方向有两个(

MySQL 查询语句优化思路

query 语句的优化思路和原则主要提现在以下几个方面:1. 优化更需要优化的Query:2. 定位优化对象的性能瓶颈:3. 明确的优化目标:4. 从 Explain 入手:5. 多使用profile6. 永远用小结果集驱动大的结果集:7. 尽可能在索引中完成排序:8. 只取出自己需要的Columns:9. 仅仅使用最有效的过滤条件:10. 尽可能避免复杂的Join和子查询 关于explain 用法:explain select * from tables1 where 1 ... 先看一下在

关于秒杀的系统架构优化思路

一.问题的提出 秒杀或抢购活动一般会经过 预约,下单,支付 ,扛不住的地方在于下单,一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题. 秒杀系统难做的原因:库存只有一份,瞬间大量用户读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万 二.架构 常见站点架构如