MySQL系统调优

最新推荐文章于 2023-07-09 11:48:38 发布
最新推荐文章于 2023-07-09 11:48:38 发布
阅读量878 收藏
点赞数
文章标签： java 多线程 并发编程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42841433/article/details/121660818
版权

MySQL系统调优


在这里插入图片描述

一、SQL调优

1、慢 SQL 语句的几种常见诱因

  • 无索引、索引失效导致慢查询

    如果在一张几千万数据的表中以一个没有索引的列作为查询条件，大部分情况下查询会非常 耗时，这种查询毫无疑问是一个慢 SQL 查询。所以对于大数据量的查询，我们需要建立适 合的索引来优化查询。虽然我们很多时候建立了索引，但在一些特定的场景下，索引还有可能会失效，所以索引失 效也是导致慢查询的主要原因之一。

  • 锁等待

    我们常用的存储引擎有 InnoDB 和 MyISAM，前者支持行锁和表锁，后者只支持表锁。

    如果数据库操作是基于表锁实现的，试想下，如果一张订单表在更新时，需要锁住整张表， 那么其它大量数据库操作（包括查询）都将处于等待状态，这将严重影响到系统的并发性 能。

    这时，InnoDB 存储引擎支持的行锁更适合高并发场景。但在使用 InnoDB 存储引擎时，我 们要特别注意行锁升级为表锁的可能。在批量更新操作时，行锁就很可能会升级为表锁。

    MySQL 认为如果对一张表使用大量行锁，会导致事务执行效率下降，从而可能造成其它事 务长时间锁等待和更多的锁冲突问题发生，致使性能严重下降，所以 MySQL 会将行锁升 级为表锁。还有，行锁是基于索引加的锁，如果我们在更新操作时，条件索引失效，那么行 锁也会升级为表锁。

    因此，基于表锁的数据库操作，会导致 SQL 阻塞等待，从而影响执行速度。在一些更新操 作（insert\update\delete）大于或等于读操作的情况下，MySQL 不建议使用 MyISAM 存储引擎

    除了锁升级之外，行锁相对表锁来说，虽然粒度更细，并发能力提升了，但也带来了新的问 题，那就是死锁。因此，在使用行锁时，我们要注意避免死锁。

  • 不恰当的 SQL 语句

    使用不恰当的 SQL 语句也是慢 SQL 最常见的诱因之一。例如，习惯使用 ， SQL 语句，在大数据表中使用 分页查询，以及对非 索引字段进行排序等等。

2、优化 SQL 语句的步骤

​ 通常，我们在执行一条 SQL 语句时，要想知道这个 SQL 先后查询了哪些表，是否使用了索 引，这些数据从哪里获取到，获取到数据遍历了多少行数据等等，我们可以通过 EXPLAIN 命令来查看这些执行信息。这些执行信息被统称为执行计划。

使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的 SQL语句的。分析你的查询语句或是表结构的性能瓶颈。

1、通过 EXPLAIN 分析 SQL 执行计划

1、准备SQL
CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content	VARCHAR(100) NULL ,PRIMARY KEY (id));
CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content	VARCHAR(100) NULL ,PRIMARY KEY (id));
CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content	VARCHAR(100) NULL ,PRIMARY KEY (id));
CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content	VARCHAR(100) NULL ,PRIMARY KEY (id));
INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000))); 
INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));
2、语法
Explain + SQL语句
3、各字段解释
1、id

select 查询的序列号,包含一组数字，表示查询中执行 select 子句或操作表的顺序。

  • id相同，执行顺序由上至下

  • id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行

  • id相同不同，同时存在

    id如果相同，可以认为是一组，从上往下顺序执行；

    在所有组中，id值越大，优先级越高，越先执行

    衍生 = DERIVED

2、select_type

select_type 代表查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询

select_type 属性含义
SIMPLE简单的 select 查询,查询中不包含子查询或者UNION
PRIMARY查询中若包含任何复杂的子部分，最外层查询则被标记为 Primary
DERIVED在 FROM 列表中包含的子查询被标记为 DERIVED(衍生)，MySQL 会递归执行这些子查询, 把结果放在临时表里。
SUBQUERY在SELECT或WHERE列表中包含了子查询
DEPEDENT SUBQUERY在SELECT或WHERE列表中包含了子查询,子查询基于外层
UNCACHEABLE SUBQUERY无法使用缓存的子查询
UNION若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED
UNION RESULT从UNION表获取结果的SELECT
  • SIMPLE代表单表查询
explain 
select * from t1;

+----+-------------+-------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | t1    | ALL  | NULL          | NULL | NULL    | NULL |    1 |       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------+
  • PRIMARY 查询中若包含任何复杂的子部分，最外层查询则被标记为 Primary。
explain 
select * from (select t1.content from t1) a;

+----+-------------+------------+--------+---------------+------+---------+------+------+-------+
| id | select_type | table      | type   | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+------------+--------+---------------+------+---------+------+------+-------+
|  1 | PRIMARY     | <derived2> | system | NULL          | NULL | NULL    | NULL |    1 |       |
|  2 | DERIVED     | t1         | ALL    | NULL          | NULL | NULL    | NULL |    1 |       |
+----+-------------+------------+--------+---------------+------+---------+------+------+-------+

  • DERIVED 在 FROM 列表中包含的子查询被标记为 DERIVED(衍生),MySQL 会递归执行这些子查询, 把结果放在临时表里

  • SUBQUERY 在select或where列表中包含了子查询

  • DEPENDENT SUBQUERY 在 SELECT 或 WHERE 列表中包含了子查询,子查询基于外层都是 where 后面的条件，subquery 是单个值，dependent subquery 是一组值。

  • UNCACHEABLE SUBQUREY 当使用了@@来引用系统变量的时候，不会使用缓存

  • UNION 若第二个 SELECT 出现在 UNION 之后，则被标记为 UNION；若 UNION 包含在 FROM 子句的子查询中,外层 SELECT 将被标记为：DERIVED

  • UNION RESULT 从 UNION 表获取结果的 SELECT。

3、table

这个数据是基于哪张表的

4、type

type 是查询的访问类型。是较为重要的一个指标，结果值从最好到最坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ，

一般来说， 得保证查询至少达到 range 级别，最好能达到 ref。

  • system

    表只有一行记录（等于系统表），这是 const 类型的特列，平时不会出现，这个也可以忽略不计

  • const

    表示通过索引一次就找到了,const 用于比较 primary key 或者 unique 索引。 因为只匹配一行数据，所以很快如将主键置于 where 列表中，MySQL 就能将该查询转换为一个常量

  • eq_ref

    唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描。

  • ref

    非唯一性索引扫描，返回匹配某个单独值的所有行.本质上也是一种索引访问， 它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行， 所以他应该属于查找和扫描的混合体

    没用索引前:

    explain select * from t1 ,t2 where t1.content = t2.content;

+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                      |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL                                       |
|  1 | SIMPLE      | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | Using where; Using join buffer (hash join) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+

    建立索引后:

    create index id_content on t2(content);

explain select * from t1 ,t2 where t1.content = t2.content;

+----+-------------+-------+------------+------+---------------+------------+---------+-----------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key        | key_len | ref             | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------------+---------+-----------------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL       | NULL    | NULL            |    1 |   100.00 | Using where |
|  1 | SIMPLE      | t2    | NULL       | ref  | id_content    | id_content | 403     | test.t1.content |    1 |   100.00 | Using index |
+----+-------------+-------+------------+------+---------------+------------+---------+-----------------+------+----------+-------------+

  • range

    只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引一般就是在 你的 where 语句中出现了 between、<、>、in 等的查询这种范围扫描索引扫描比全 表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。

    explain select * from t1 where t1.id < 10;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL |    1 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+

explain select * from t1 where t1.id in (10,13,15);
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL |    3 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+

  • index

    出现index是sql使用了索引但是没用通过索引进行过滤，一般是使用了覆盖索引或者是利用索引进行了排序分组

    explain select * from t1 ;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+

explain select id from t1 ;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | index | NULL          | PRIMARY | 4       | NULL |    1 |   100.00 | Using index |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+

  • all

    将遍历全表以找到匹配的行

  • index_merge

    在查询过程中需要多个索引组合使用，通常出现在有 or 的关键字的 sql 中。

  • ref_or_null

    对于某个字段既需要关联条件，也需要 null 值得情况下。查询优化器会选择用 ref_or_null 连接查询。

  • index_subquery

    explain select * from t2 where t2.content in (select t3.content from t3);
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type        | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | PRIMARY            | t2    | ALL  | NULL          | NULL | NULL    | NULL |    1 | Using where |
|  2 | DEPENDENT SUBQUERY | t3    | ALL  | NULL          | NULL | NULL    | NULL |    1 | Using where |
+----+--------------------+-------+------+---------------+------+---------+------+------+-------------+

create index idx_ctnt on t3(content);

explain select * from t2 where t2.content in (select t3.content from t3);
+----+--------------------+-------+----------------+---------------+----------+---------+------+------+--------------------------+
| id | select_type        | table | type           | possible_keys | key      | key_len | ref  | rows | Extra                    |
+----+--------------------+-------+----------------+---------------+----------+---------+------+------+--------------------------+
|  1 | PRIMARY            | t2    | ALL            | NULL          | NULL     | NULL    | NULL |    1 | Using where              |
|  2 | DEPENDENT SUBQUERY | t3    | index_subquery | idx_ctnt      | idx_ctnt | 403     | func |    1 | Using index; Using where |
+----+--------------------+-------+----------------+---------------+----------+---------+------+------+--------------------------+

  • unique_subquery

    该联接类型类似于 index_subquery。 子查询中的唯一索引

    explain select * from t2 where t2.id in (select t3.id from t3);
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+-------------+
| id | select_type        | table | type            | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+-------------+
|  1 | PRIMARY            | t2    | ALL             | NULL          | NULL    | NULL    | NULL |    1 | Using where |
|  2 | DEPENDENT SUBQUERY | t3    | unique_subquery | PRIMARY       | PRIMARY | 4       | func |    1 | Using index |
+----+--------------------+-------+-----------------+---------------+---------+---------+------+------+-------------+
5、possible_keys

显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出， 但不一定被查询实际使用。

6、key

实际使用的索引。如果为NULL，则没有使用索引。

7、key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。 key_len 字段能够帮你检查是否充分的 利用上了索引。ken_len 越长，说明索引使用的越充分。

①先看索引上字段的类型+长度比如 int=4 ; varchar(20) =20 ; char(20) =20

②如果是 varchar 或者 char 这种字符串字段，视字符集要乘不同的值，比如 utf-8 要乘 3,GBK 要乘 2，

③varchar 这种动态字符串要加 2 个字节

④允许为空的字段要加 1 个字节 第一组：key_len=age 的字节长度+name 的字节长度=4+1 + ( 20*3+2)=5+62=67 第二组：key_len=age 的字节长度=4+1=5

8、ref

显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值

9、rows

rows 列显示 MySQL 认为它执行查询时必须检查的行数。越少越好！

10、Extra

其他的额外重要的信息

Using filesort

说明 mysql 会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL 中无法利用索引 完成的排序操作称为“文件排序”。

查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度。

Using temporary

使了用临时表保存中间结果,MySQL 在对查询结果排序时使用临时表。 常见于排序 order by 和分组查询 group by。

Using index

Using index 代表表示相应的 select 操作中使用了覆盖索引(Covering Index)， 避免访问了表的数据行，效率不错！如果同时出现 using where，表明索引被用来执行 索引键值的查找;如果没有同时出现 using where，表明索引只是用来读取数据而非利 用索引执行查找。利用索引进行了排序或分组。

Using where

表明使用了 where 过滤

Using join buffer

使用了连接缓存

impossible where

where 子句的值总是 false，不能用来获取任何元组

select tables optimized away

在没有 GROUPBY 子句的情况下，基于索引优化 MIN/MAX 操作或者对于 MyISAM 存储引擎优化 COUNT(*)操作，不必等到执行阶段再进行计算， 查询执行计划生成的阶段即完成优化。

二、索引优化

1、索引分析

1、单表

1、建表sql
CREATE TABLE IF NOT EXISTS `article` (
`id` INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
`author_id` INT(10) UNSIGNED NOT NULL,
`category_id` INT(10) UNSIGNED NOT NULL,
`views` INT(10) UNSIGNED NOT NULL,
`comments` INT(10) UNSIGNED NOT NULL,
`title` VARBINARY(255) NOT NULL,
`content` TEXT NOT NULL
);

INSERT INTO `article`(`author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES
(1, 1, 1, 1, '1', '1'),
(2, 2, 2, 2, '2', '2'),
(1, 1, 3, 3, '3', '3');
2、案例分析
1、查询 category_id 为 1 且 comments 大于 1 的情况下,views 最多的 article_id。
EXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                       |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+
|  1 | SIMPLE      | article | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    3 |    33.33 | Using where; Using filesort |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-----------------------------+

很显然,type 是 ALL,即最坏的情况。Extra 里还出现了 Using filesort,也是最坏的情况。优化是必须的。

2、开始优化
create index idx_article_ccv on article(category_id,comments,views);

EXPLAIN SELECT id,author_id FROM `article` WHERE category_id = 1 AND comments >1 ORDER BY views DESC LIMIT 1;
EXPLAIN SELECT id,author_id FROM `article` WHERE category_id = 1 AND comments =3 ORDER BY views DESC LIMIT 1
#结论：
#type 变成了 range,这是可以忍受的。但是 extra 里使用 Using filesort 仍是无法接受的。
#但是我们已经建立了索引,为啥没用呢?
#这是因为按照 BTree 索引的工作原理,
# 先排序 category_id,
# 如果遇到相同的 category_id 则再排序 comments,如果遇到相同的 comments 则再排序 views。
#当 comments 字段在联合索引里处于中间位置时,
#因comments > 1 条件是一个范围值(所谓 range),
#MySQL 无法利用索引再对后面的 views 部分进行检索,即 range 类型查询字段后面的索引无效

#删除第一次建立的索引
DROP INDEX idx_article_ccv ON article;
 
#第2次新建索引
#ALTER TABLE `article` ADD INDEX idx_article_cv ( `category_id` , `views` ) ;
create index idx_article_cv on article(category_id,views);
 
#第3次EXPLAIN
EXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
#结论：可以看到,type 变为了 ref,Extra 中的 Using filesort 也消失了,结果非常理想。
DROP INDEX idx_article_cv ON article;

2、两表

1、建表sql
 CREATE TABLE IF NOT EXISTS `class` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE IF NOT EXISTS `book` (
`bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`bookid`)
);
 
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
 
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
2、案例分析
 
# 下面开始explain分析
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
#结论：type 有All
 
# 添加索引优化
ALTER TABLE `book` ADD INDEX Y ( `card`);
 
# 第2次explain
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
#可以看到第二行的 type 变为了 ref,rows 也变成了优化比较明显。
#这是由左连接特性决定的。LEFT JOIN 条件用于确定如何从右表搜索行,左边一定都有,
#所以右边是我们的关键点,一定需要建立索引。
 
# 删除旧索引 + 新建 + 第3次explain
DROP INDEX Y ON book;
ALTER TABLE class ADD INDEX X (card);
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
 
 
# 然后来看一个右连接查询:
#优化较明显。这是因为 RIGHT JOIN 条件用于确定如何从左表搜索行,右边一定都有,所以左边是我们的关键点,一定需要建立索引。
EXPLAIN SELECT * FROM class RIGHT JOIN book ON class.card = book.card;
DROP INDEX X ON class;
ALTER TABLE book ADD INDEX Y (card);
# 右连接，基本无变化
EXPLAIN SELECT * FROM class RIGHT JOIN book ON class.card = book.card;

3、三表

1、建表sql
 
CREATE TABLE IF NOT EXISTS `phone` (
`phoneid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`phoneid`)
) ENGINE = INNODB;
 
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO phone(card) VALUES(FLOOR(1 + (RAND() * 20)));
2、案例分析
 
 
ALTER TABLE `phone` ADD INDEX z ( `card`);
 
ALTER TABLE `book` ADD INDEX Y ( `card`);#上一个case建过一个同样的
 
 
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card=book.card LEFT JOIN phone ON book.card = phone.card;
 
# 后 2 行的 type 都是 ref 且总 rows 优化很好,效果不错。因此索引最好设置在需要经常查询的字段中。
==================================================================================
【结论】
Join语句的优化
 
尽可能减少Join语句中的NestedLoop的循环总次数；“永远用小结果集驱动大的结果集”。
优先优化NestedLoop的内层循环；
保证Join语句中被驱动表上Join条件字段已经被索引；
当无法保证被驱动表的Join条件字段被索引且内存资源充足的前提下，不要太吝惜JoinBuffer的设置；

2、索引失效(应该避免)

 
CREATE TABLE staffs (
  id INT PRIMARY KEY AUTO_INCREMENT,
  NAME VARCHAR (24) NOT NULL DEFAULT '' COMMENT '姓名',
  age INT NOT NULL DEFAULT 0 COMMENT '年龄',
  pos VARCHAR (20) NOT NULL DEFAULT '' COMMENT '职位',
  add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间'
) CHARSET utf8 COMMENT '员工记录表' ;
 
 
INSERT INTO staffs(NAME,age,pos,add_time) VALUES('z3',22,'manager',NOW());
INSERT INTO staffs(NAME,age,pos,add_time) VALUES('July',23,'dev',NOW());
 
SELECT * FROM staffs;
 
ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

1、全值匹配我最爱

# 注意看 ref
EXPLAIN SELECT * FROM staffs WHERE NAME = 'July';
EXPLAIN SELECT * FROM staffs WHERE NAME = 'July' AND age = 25;
EXPLAIN SELECT * FROM staffs WHERE NAME = 'July' AND age = 25 AND pos = 'dev';

mysql> EXPLAIN SELECT * FROM staffs WHERE NAME = 'July';
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref   | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+

mysql> EXPLAIN SELECT * FROM staffs WHERE NAME = 'July' AND age = 25;
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref         | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 78      | const,const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------+------+----------+-------+

mysql> EXPLAIN SELECT * FROM staffs WHERE NAME = 'July' AND age = 25 AND pos = 'dev';
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref               | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 140     | const,const,const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------------+------+----------+-------+

2、最佳左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。

EXPLAIN SELECT * FROM staffs WHERE age = 25 AND pos = 'dev';
EXPLAIN SELECT * FROM staffs WHERE pos = 'dev';
EXPLAIN SELECT * FROM staffs WHERE name = 'July';

mysql> EXPLAIN SELECT * FROM staffs WHERE age = 25 AND pos = 'dev';
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | staffs | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |    50.00 | Using where |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+

mysql> EXPLAIN SELECT * FROM staffs WHERE pos = 'dev';
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | staffs | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |    50.00 | Using where |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+

mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July';
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref   | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+

3、不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

EXPLAIN SELECT * FROM staffs WHERE left(NAME,4) = 'July';

mysql> EXPLAIN SELECT * FROM staffs WHERE left(NAME,4) = 'July';
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | staffs | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | Using where |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+

索引列上使用了表达式，如where substr(a, 1, 3) = ‘hhh’，where a = a + 1，表达式是一大忌讳，再简单mysql也不认。有时数据量不是大到严重影响速度时，一般可以先查出来，比如先查所有有订单记录的数据，再在程序中去筛选

4、存储引擎不能使用索引中范围条件右边的列

EXPLAIN SELECT * FROM staffs WHERE name = 'July';
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref   | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+


EXPLAIN SELECT * FROM staffs WHERE name = 'July' and age = 20;
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref         | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 78      | const,const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------+------+----------+-------+

5、尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select *

explain select name,age,pos from staffs where name = 'July' and age = 20 and pos = 'dev';
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref               | rows | filtered | Extra       |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------------+------+----------+-------------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 140     | const,const,const |    1 |   100.00 | Using index |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------------------+------+----------+-------------+

explain select * from staffs where name = 'July' and age = 20 and pos = 'dev';

6、mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描

EXPLAIN SELECT * FROM staffs WHERE name = 'July';
 +----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys         | key                   | key_len | ref   | rows | filtered | Extra |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ref  | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | const |    1 |   100.00 | NULL  |
+----+-------------+--------+------------+------+-----------------------+-----------------------+---------+-------+------+----------+-------+

EXPLAIN SELECT * FROM staffs WHERE name != 'July';
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
| id | select_type | table  | partitions | type  | possible_keys         | key                   | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | staffs | NULL       | range | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | NULL |    2 |   100.00 | Using index condition |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+

EXPLAIN SELECT * FROM staffs WHERE name <> 'July';
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
| id | select_type | table  | partitions | type  | possible_keys         | key                   | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | staffs | NULL       | range | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | NULL |    2 |   100.00 | Using index condition |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+

7、is null ,is not null 也无法使用索引

EXPLAIN SELECT * FROM staffs WHERE name is null;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra            |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | Impossible WHERE |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------+

EXPLAIN SELECT * FROM staffs WHERE name is not null;
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | staffs | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | NULL  |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------+

8、like以通配符开头(’%abc…’)mysql索引失效会变成全表扫描的操作

EXPLAIN SELECT * FROM staffs WHERE name like '%q';
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | staffs | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |    50.00 | Using where |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+-------------+

EXPLAIN SELECT * FROM staffs WHERE name like 'q%';
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
| id | select_type | table  | partitions | type  | possible_keys         | key                   | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | staffs | NULL       | range | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | NULL |    1 |   100.00 | Using index condition |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+

9、字符串不加单引号索引失效

EXPLAIN SELECT * FROM staffs WHERE name = 903;
+----+-------------+--------+------------+------+-----------------------+------+---------+------+------+----------+-------------+
| id | select_type | table  | partitions | type | possible_keys         | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+--------+------------+------+-----------------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | staffs | NULL       | ALL  | idx_staffs_nameAgePos | NULL | NULL    | NULL |    2 |    50.00 | Using where |
+----+-------------+--------+------------+------+-----------------------+------+---------+------+------+----------+-------------+

10、少用or,用它来连接时会索引失效(8.0不会)

EXPLAIN SELECT * FROM staffs WHERE name = 'July' or name = 'hh';
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
| id | select_type | table  | partitions | type  | possible_keys         | key                   | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | staffs | NULL       | range | idx_staffs_nameAgePos | idx_staffs_nameAgePos | 74      | NULL |    2 |   100.00 | Using index condition |
+----+-------------+--------+------------+-------+-----------------------+-----------------------+---------+------+------+----------+-----------------------+

11、总结

Where语句索引是否被使用
where a = 3Y,使用到a
where a = 3 and b = 5Y,使用到a，b
where a = 3 and b = 5 and c = 4Y,使用到a,b,c
where b = 3 where b = 3 and c = 4 where c = 4N
where a = 3 and c = 5使用到a， 但是C不可以，中间断了
where a = 3 and b > 4 and c = 7使用到a和b， c在范围之后，断了
where a = 3 and b like ‘kk%’ and c = 4使用到a和b， c在范围之后，断了
小薛博客
关注
mysql之优化-系统优化
王道长的技术博客
05-13 716
一、内存 1.1 要确保有足够的内存 数据库能够高效的运行，最关建的因素需要内存足更大了，能缓存住数据，更新也可以在内存先完成。但不同的业务对内存需要强度不一样，一推荐内存要占到数据的15-25%的比例，特别的热的数据，内存基本要达到数据库的80%大小。 拥有足够的物理内存来把整个InnoDB文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。 1.2 选择合适的内存分配算法 默...
mysql系统调优
夕时明月
12-08 203
sysbench：一个模块化，跨平台以及多线程的性能测试工具. iibench-mysql：基于 Java 的 MySQL/Percona/MariaDB 索引进行插入性能测试工具;tpcc-mysql：Percona开发的TPC-C测试工具
MySQL调优
tianyuan233
04-19 407
MySQL调优可以从几个方面来做：1. 架构层：做从库，实现读写分离；2.系统层次：1.增加内存； 2.给磁盘做raid0或者raid5以增加磁盘的读写速度； 3.可以重新挂载磁盘，并加上noatime参数，这样可以减少磁盘的i/o;3. MySQL本身调优：(1) 如果未配置主从同步，可以把bin-log功能关闭，减少磁盘i/o (2) 在my.cnf中加上skip-name-resol
MySQL参数级优化和系统级优化
xiao1xuan2的博客
07-02 424
最近学习了一点MySQL数据库的优化，于是乎就想写一写自己的心得与体会。
mysql调优
maqingbin8888的专栏
11-19 314
事物的执行时长 #查询事物执行时间超过60S的 长事物 select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))&gt;60  
MySQL性能调优与架构设计.pdf
01-19
"MySQL性能调优与架构设计.pdf" 本资源摘要信息是关于 MySQL 数据库软件的性能调优和架构设计的知识点。MySQL 是一个流行的开源数据库管理系统，具有简单高效可靠的特点，广泛应用于各个行业。以下是从给定的文件中...
MYSQL调优MYSQL调优MYSQL调优MYSQL调优MYSQL调优MYSQL调优
06-20
MySQL 调优是数据库管理中的关键环节，目的是提升数据查询效率，减少资源消耗，从而提高整体系统性能。针对给定的问题，我们将分析并提供相应的优化策略。 问题一涉及对表 `user1` 的查询优化。原查询语句如下： ``...
基于MySQL性能调优的推荐系统优化设计.pdf
最新发布
02-02
### 基于MySQL性能调优的推荐系统优化设计 #### 概述 在当前的大数据环境下，数据处理与分析面临着前所未前的挑战。对于基于MySQL数据库构建的应用系统而言，如何提升其性能以应对日益增长的数据量和用户访问量...
2021年MySQL性能调优与架构设计整理.pdf
04-07
综上所述，MySQL作为一款成熟的开源数据库管理系统，其性能调优与架构设计对于提高系统的整体性能至关重要。通过对MySQL的基础了解、功能模块协同工作原理以及Query处理流程的深入探讨，可以更好地理解和掌握如何...
【MySQL调优】如何进行MySQL调优？一篇文章就够了！
热门推荐
vincewm的博客
06-06 2万+
MySQL调优主要分为三个步骤：监控报警、排查慢SQL、MySQL调优。 排查慢SQL：开启慢查询日志 、找出最慢的几条SQL、分析查询计划 。 MySQL调优： 基础优化：缓存优化、硬件优化、参数优化、定期清理垃圾、使用合适的存储引擎、读写分离、分库分表； 表设计优化：数据类型优化、冷热数据分表等。 索引优化：考虑索引失效的11个场景、遵循索引设计原则、连接查询优化、排序优化、深分页查询优化、覆盖索引、索引下推、用普通索引等。 SQL优化。
MySql调优
m0_51044151的博客
04-13 577
Mysql性能优化就是通过合理安排资源，调整系统参数使MySql运行更快、更节省资源。 mysql调优其实就是从时间、空间这两个方面来进行优化 mysql怎么调优 第一：选择最合适的字段属性。 mysql在创建数据库的时候肯定是数据库中的表越小越好，这样才能提高查询的速度。但是现实往往不如人意，每天可能产生的数据量是以数万或者数十万为单位的，这时就要充分地考虑在建表时的字段长度了。比如说在存储电话号的时候，如果将其写成CHAR(255),这显然会给数据库带来很多不必要的空间浪费，明明CHAR（11）就可以解
mysql服务器硬件_关于MySQL服务器硬件和OS（操作系统）调优的24条建议
weixin_31313019的博客
01-28 165
概述MySQL是一个强大的开源数据库。随着MySQL上的应用越来越多，MySQL逐渐遇到了瓶颈。这里提供一些关于MySQL服务器硬件和OS(操作系统)调优的建议。优化建议1、足够的内存有足够的物理内存，能将整个InnoDB文件加载到内存里 —— 如果访问的文件在内存里，而不是在磁盘上，InnoDB会快很多。2、避免swap要尽力避免 Swap 操作 — 交换(swapping)是从磁盘读取数据，所...
MySQL优化配置文件my.ini
Kevin.Chen - 专注前行
10-16 987
公司网站访问量越来越大，MySQL自然成为瓶颈，因此最近我一直在研究 MySQL 的优化，第一步自然想到的是 MySQL 系统参数的优化，作为一个访问量很大的网站（日20万人次以上）的数据库系统，不可能指望 MySQL 默认的系统参数能够让 MySQL运行得非常顺畅。   在Apache, PHP, MySQL的体系架构中，MySQL对于性能的影响最大，也是关键的核心部分。对于Discuz!论
mysql的调优策略_常用MYSQL性能调优策略之系统级别调优（1）
weixin_39568706的博客
02-19 103
第一章　MySQL企业常用架构应用实战(主从复制+性能调优)1、企业级MySQL发行版Percona Server、MariaDB选型2、常用MYSQL性能调优策略之系统级别调优(1)3、常用MYSQL性能调优策略之系统级别调优(2)4、常用MYSQL性能调优策略之MySQL参数调优(1)5、常用MYSQL性能调优策略之MySQL参数调优(2)6、常用MYSQL性能调优策略之MySQL参数调优(3...
MySQL性能调优的10个方法（转载）-20230709
u010503464的博客
07-09 4356
MySQL性能调优的10个方法
Mysql调优策略
sasibingdu的博客
04-03 2731
mysql调优
MySQL性能优化的参数简介
wangwangxiang918的专栏
09-29 495
公司网站访问量越来越大，MySQL自然成为瓶颈，因此最近我一直在研究 MySQL 的优化，第一步自然想到的是 MySQL 系统参数的优化，作为一个访问量很大的网站（日20万人次以上）的数据库系统，不可能指望 MySQL 默认的系统参数能够让 MySQL运行得非常顺畅。在Apache, PHP, MySQL的体系架构中，MySQL对于性能的影响最大，也是关键的核心部分。对于Discuz!论坛程序也是如此，MySQL的设置是否合理优化，直接影响到论坛的速度和承载量！同时，MySQL也是优化难度最大的一个部分，不
解读MySQL性能调优“金字塔”
博文视点（北京）官方博客
10-22 2917
计算机是一种实验的科学，性能优化是实战的艺术 蒸汽机的改进不是一蹴而就的，MySQL性能的改进也是贯穿整个MySQL发展史的。MySQL之父Monty在1981年写了MySQL的第一行代码以后，在开源的帮助下MySQL成长为目前最流行的开源数据库，同样其也凝聚了非常多的开发者、DBA、工程师的心血。 本文选自《千金良方：MySQL性能优化金字塔法则》一书，将从整体上介绍性能调优的几个方面，并借用“...
2023最强Docker教程
小薛博客助力人人成为架构师
11-08 3175
Docker精讲一、基本概念1、Docker架构2、Docker隔离原理3、 Docker 如何工作？4、Docker安装1、移除旧版本2、设置docker yum源3、安装最新docker engine (可不安装)4、安装指定版本docker engine1、在线安装2、离线安装5、启动服务6、镜像加速7、可视化界面-Portainer1、什么是Portainer2、安装5、Docker镜像生命周期二、镜像、容器1、常见命令1、docker ps2、docker images3、docker pull4
MySQL性能调优实战指南
MySQL性能调优是一个系统性的工作，需要综合考虑数据库设计、SQL优化、存储过程和应用层面等多个维度。只有深入理解每个环节，才能做出有针对性的优化决策，从而提升整个数据库系统的性能。现在，就轮到你自己动手...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小薛博客

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值