mysql优化介绍

最新推荐文章于 2024-09-24 09:50:23 发布
最新推荐文章于 2024-09-24 09:50:23 发布
阅读量223 收藏 1
点赞数
分类专栏： 数据库 数据结构 文章标签： mysql 数据库 sql优化
原文链接：https://mp.weixin.qq.com/s/ZpeUn4d9aoI4o3Mx0ivG5Q
版权

当面对一个sql性能问题，我们应该从何处入手使得尽快定位问题sql，我们从基础的命令开始。

数据库优化

1.查看各种命令的执行频率

mysql> show status like 'Com_%' \g
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Com_admin_commands        | 0     |
| Com_assign_to_keycache    | 0     |
| Com_alter_db              | 0     |
| Com_alter_db_upgrade      | 0     |
| Com_alter_event           | 0     |
| Com_alter_function        | 0     |
| Com_alter_procedure       | 0     |
| Com_alter_server          | 0     |
| Com_alter_table           | 0     |
| Com_alter_tablespace      | 0     |
| Com_alter_user            | 0     |
| Com_analyze               | 0     |
| Com_begin                 | 0     |
| Com_binlog                | 0     |
| Com_call_procedure        | 0     |
| Com_change_db             | 0     |
| Com_change_master         | 0     |
| Com_check                 | 0     |
| Com_checksum              | 0     |
| Com_commit                | 0     |

Com_xxx表示每个xxx语句执行的次数，创建的的参数如下

Com_select :执行select操作的次数，一次查询累加一次。

Com_insert: 执行insert操作的次数，批量插入累加一次

Com_delete:执行delete操作的次数

Com_update:执行update操作的次数

下面的参数只针对InnoDB存储引擎，累加的算法也略有不通。

Innodb_rows_read:select查询返回的行数。

Innodb_rows_inserted:insert插入的的行数。

innodb_rows_deleted:delete删除的行数。

innodb_rows_updated:update更新的行数，不管是提交还是回滚都会进行累加。

上面命令可以查出你的数据库到底是以查询为主，还是更新操作为主。

对于事物型的应用，通过Com_commit和Com_rollback可以了解提交和回滚的情况，对于回滚此处过多，就有可能是编程出现了问题。

下面参数是了解数据库的基本情况

Connections:试图连接Mysql服务器的次数。

Uptime:服务器工作时间。

Slow_queries:慢查询的次数。

2.定位执行效率低的sql语句

通过慢查询日志定位那些sql执行效率低，通过--log_slow-queries[=file-names]选项启动，mysqld会记录一个超过long_query_time秒的日志文件。

 

慢查询日志是在应用执行完之后记录的，索引应用在出现sql效率的问题上并能定位问题，我们可以使用 show processlist命令查看当前mysql在进行的线程，包括线程的状态，是够锁表，可以实时的查看sql的执行情况，同时对一些锁表操作进行优化。

3通过explain分析低效率的sql执行计划

通过上面步骤查看到低效率的sql之后，我们就可以使用explain或desc命令获取mysql如何执行select语句的信息,包括如何连接和链接的顺序。

我们先看几个参数的说明

select_type:表示select类型。常见的取值有SIMPLE(简单表，既不是用表连接或子查询)PRIMARY(朱查询，即外层查询)，UNION( UNION中的第二哥或者后面的查询语句)SUBQUERY(子查询的第一个select)

table:输出结果的表。

type:访问类型，在表中找到所需行的方式。

从左到右，性能依次最好。

  • type=ALL,全表扫描

mysql> explain select  * from film where rating>9\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: film
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1000
        Extra: Using where
1 row in set (0.00 sec)

  • type=index.索引全扫描，mysql遍历整个多音来查询匹配的行

mysql> explain select title from film\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: film
         type: index
possible_keys: NULL
          key: idx_title
      key_len: 767
          ref: NULL
         rows: 1000
        Extra: Using index
1 row in set (0.00 sec)

  • type=range.索引范围查询，常用语>,<,<=,>=,between

mysql> explain select * from payment where customer_id>=300 and customer_id<350\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: payment
         type: range
possible_keys: idx_fk_customer_id
          key: idx_fk_customer_id
      key_len: 2
          ref: NULL
         rows: 1325
        Extra: Using index condition
1 row in set (0.00 sec)

  • type=ref,使用非唯一索引或唯一索引前缀扫描，返回某个单独之的记录行

mysql> explain select *  from payment where customer_id=350\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: payment
         type: ref
possible_keys: idx_fk_customer_id
          key: idx_fk_customer_id
      key_len: 2
          ref: const
         rows: 23
        Extra: NULL
1 row in set (0.00 sec)

  • type=eq_ref,类似ref,区别是使用的是唯一索引，对于每个索引键值，表中只有一条记录匹配，简单是多表链接中使用primary_key或unique index作为关联条件、

mysql> explain select * from film a, film_text b where a.film_id =b.film_id\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: b
         type: ALL
possible_keys: PRIMARY
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1000
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: a
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 2
          ref: sakila.b.film_id
         rows: 1
        Extra: Using where
2 rows in set (0.00 sec)

  • type=const/system，单表中最多匹配一行数据，查询非常迅速，所以这个匹配行中的 其他列的值可以被优化器在当前查询中当做常量来处理。例如根据主键或者唯一索引进行查询。

mysql> explain select  *   from (select  * from customer where email='AARON.SELBY@SAKILACUSTOMER.ORG')a\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: system
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1
        Extra: NULL
*************************** 2. row ***************************
           id: 2
  select_type: DERIVED
        table: customer
         type: const
possible_keys: uk_email
          key: uk_email
      key_len: 153
          ref: const
         rows: 1
        Extra: NULL
2 rows in set (0.00 sec)

  • type=null,不用访问表或索引，直接就返回结果。

mysql> explain select   1 from dual where 1\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: NULL
         type: NULL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
        Extra: No tables used
1 row in set (0.00 sec)

类型type还有其他值，如ref_or_null(与ref类似，区别是对查询条件包含null值查询)，index_merge(索引合并优化)，unique_subquery(in的后面是一个查询主键字段的子查询)，index_subquery(与unique_subquery类似，区别是在于in的后面是查询非唯一索引字段的子查询)等，

  • possible_key:表示查询可能使用的索引

  • key：实际使用的索引

  • key_len：使用索引的的字段长度

  • rows:扫描行的数目

  • extra:执行情况的说明和 描述，包含不适合在其他列中显示但是对执行计划非常重要的额外信息.

mysql4.1引入了explain extended 命令，通过explain extended和show warnings,w我们能够看到sql真正执行之前优化器做了哪些优化，在mysql 5.1开始支持分区的功能，同时可以使用explain partitions 查看数据结果多需要访问的分区名称。

4.show profile分析sql

首先查看是否支持show profile，如果支持，开启profiling,如下是否支持使用

select @@have_profiling.

mysql> select @@have_profiling;  //是否支持show profiling
+------------------+
| @@have_profiling |
+------------------+
| YES              |
+------------------+
1 row in set, 1 warning (0.00 sec)

mysql> select @@profiling;  //默认关闭
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> set profiling=1;  //开启profiling
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           1 |
+-------------+
1 row in set, 1 warning (0.01 sec)

 通过profile，我们可以更清楚的了解sql执行的过程，比如，我使用count(*).我们知道myisam表使用count(*)是不需要小号太多资源的，相对于Innodb就没有这种元数据缓存，count(*)执行的较慢，如下

mysql> select count(*) from payment;
+----------+
| count(*) |
+----------+
|    16049 |
+----------+
1 row in set (0.01 sec)

使用show profiles查看query_id

mysql> show profiles;
+----------+------------+------------------------------+
| Query_ID | Duration   | Query                        |
+----------+------------+------------------------------+
|        1 | 0.00350500 | select @@profiling           |
|        2 | 0.00863050 | select count(*) from payment |
+----------+------------+------------------------------+
2 rows in set, 1 warning (0.00 sec)

在使用show profiling for query 查看执行过程的每个线程状态和消耗的时间

mysql> show profile for query 2;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000506 |
| checking permissions | 0.000272 |
| Opening tables       | 0.000467 |
| init                 | 0.000039 |
| System lock          | 0.000229 |
| optimizing           | 0.000231 |
| statistics           | 0.000040 |
| preparing            | 0.000222 |
| executing            | 0.000083 |
| Sending data         | 0.006353 |
| end                  | 0.000024 |
| query end            | 0.000013 |
| closing tables       | 0.000022 |
| freeing items        | 0.000090 |
| cleaning up          | 0.000041 |
+----------------------+----------+
15 rows in set, 1 warning (0.00 sec)

我们发现消耗的时间在 sending data(表示mysql线程开始访问数据，到返回到客户端，而不是仅仅返回结果给客户端，sending data 状态往往需要做大量的磁盘读取操作，所以往往是访问消耗最长的状态)，

我们也可以查看mysql在上什么资源(all,cpu，block io,context switch,page faults)上消耗过高的时间，例如，查看CPU

mysql> show profile cpu for query 2;
+----------------------+----------+----------+------------+
| Status               | Duration | CPU_user | CPU_system |
+----------------------+----------+----------+------------+
| starting             | 0.000506 | 0.000000 |   0.000000 |
| checking permissions | 0.000272 | 0.000000 |   0.000000 |
| Opening tables       | 0.000467 | 0.000000 |   0.000000 |
| init                 | 0.000039 | 0.000000 |   0.000000 |
| System lock          | 0.000229 | 0.000000 |   0.000000 |
| optimizing           | 0.000231 | 0.000000 |   0.000000 |
| statistics           | 0.000040 | 0.000000 |   0.000000 |
| preparing            | 0.000222 | 0.000000 |   0.000000 |
| executing            | 0.000083 | 0.000000 |   0.000000 |
| Sending data         | 0.006353 | 0.010000 |   0.000000 |
| end                  | 0.000024 | 0.000000 |   0.000000 |
| query end            | 0.000013 | 0.000000 |   0.000000 |
| closing tables       | 0.000022 | 0.000000 |   0.000000 |
| freeing items        | 0.000090 | 0.000000 |   0.000000 |
| cleaning up          | 0.000041 | 0.000000 |   0.000000 |
+----------------------+----------+----------+------------+
15 rows in set, 1 warning (0.01 sec)

使用myisam存储引擎，效率就比较好，完全不需要访问数据

mysql> create table payment_myisam like payment;
Query OK, 0 rows affected (0.05 sec)

mysql> alter table payment_myisam engine=myisam;
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> insert into payment_myisam select  *  from payment;
Query OK, 16049 rows affected (0.09 sec)
Records: 16049  Duplicates: 0  Warnings: 0

mysql> select count(*) from payment_myisam;
+----------+
| count(*) |
+----------+
|    16049 |
+----------+
1 row in set (0.00 sec)

使用show profiles  查看queryid ,查看queryid消耗在哪个状态以及时间

mysql> show profiles
    -> ;
+----------+------------+----------------------------------------------------+
| Query_ID | Duration   | Query                                              |
+----------+------------+----------------------------------------------------+
|        1 | 0.00350500 | select @@profiling                                 |
|        2 | 0.00863050 | select count(*) from payment                       |
|        3 | 0.00044600 | set @query_id :=2                                  |
|        4 | 0.00038475 | select state ,sum(duration) as total_r,            |
|        5 | 0.05704400 | create table payment_myisam like payment           |
|        6 | 0.05384750 | alter table payment_myisam engine=myisam           |
|        7 | 0.08750150 | insert into payment_myisam select  *  from payment |
|        8 | 0.00061250 | select count(*) from payment_myisam                |
+----------+------------+----------------------------------------------------+
8 rows in set, 1 warning (0.00 sec)

mysql> show profile for query 8;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000115 |
| checking permissions | 0.000035 |
| Opening tables       | 0.000064 |
| init                 | 0.000054 |
| System lock          | 0.000053 |
| optimizing           | 0.000023 |
| executing            | 0.000022 |
| end                  | 0.000023 |
| query end            | 0.000022 |
| closing tables       | 0.000037 |
| freeing items        | 0.000048 |
| cleaning up          | 0.000117 |
+----------------------+----------+
12 rows in set, 1 warning (0.00 sec)

发现在myisam存储引擎中，在executing之后就直接结束查询了，完全不需要访问数据。

经过以上步骤基本就可确定问题出现在哪里，此时可以采用响应的措施，进行提高执行的效率。最常见的措施就是添加索引。

 

常用的sql优化

大量插入数据

MyiSam存储引擎的表，进行大量导入数据，可以使用，但是对于Innodb存储引擎这种方式并不能提高导入效率。我们可以使用下面几条规则：

1.因为Innodb存储引擎的表示按照主键顺序保存的，我们按照主键顺序排序，可以提高导入顺序

2.在导入数据前执行set unique_checks=0,关闭唯一索引校验，在导入后执行set unique_checks=1,恢复唯一性校验，可以恢复导入的效率

如果应用使用自动提交的方式，建议在导入数据之前执行 set autocommit=0,关闭自动提交，结束之后再执行set autocommit=1.打开自动提交，

优化insert 语句

  1. 如果从同一个客户端插入很多行，使用多个值表的insert语句，这种将大大的减少客户端和数据库之间的连接诶，关闭消耗，inset into test values (1,2) ,(3,4),(5,6)

  2. 如果从不同的客户端插入很多行，可以通过insert delayed 语句得到更高的速度，delayed的含义是让insert语句马上执行，其实数据都被放到了内存的队列中，并没有进行真正写入磁盘，low_priority刚好相反，在所有用户对表读写完成之后进行插入，

  3. 将索引文件和数据文件放在不同的磁盘存放

  4. 如果进行批量插入的时候，可以设置bulk_insert_buffer_size变量值的方法来提高速度，但是这个只对MyISAM表使用

  5. 当从一个文件装载一个表的时候，可以使用load data infile.

优化order by 

优化ordder by 先要了解mysql的排序方式

第一种就是通过有序索引扫描直接返回有序数据，

mysql> explain select customer_id from customer order by store_id\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: customer
         type: index
possible_keys: NULL
          key: idx_fk_store_id
      key_len: 1
          ref: NULL
         rows: 599
        Extra: Using index
1 row in set (0.00 sec)

第二种通过返回的数据进行排序，也就是Filesort,不通过索引直接返回排序结果排序Filesort,

mysql> explain select  *  from customer order by store_id\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: customer
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 599
        Extra: Using filesort
1 row in set (0.00 sec)

Filesort是通过响应的排序算法，将取得的数据在sort_buffer_size系统变量设置的内存排序去中进行排序，如果内存装载不下，他讲在磁盘上进行数据进行分块，在对每个数据块进行排序，然后将各个块进行合并成有序的集合，sort_buffer_size是对每一个线程独有的，所以在mysql的同一时刻，会存在多个sort_buffer_size.

所以我们优化order by  的策略就是尽量的不进行额外的排序，通过索引直接返回有序的数据，where 条件和order by 使用相同的索引，且order  by  的顺序和索引的顺序相同，order by 是降序或升序，否则就会进行额外的排序，这样就会出现Filesort,

总结一下使用sql会使用索引

select * from table order by key_part1 ,key_part2
select * from table where key_part1=1 order by key_part1 desc, key_part2 desc
select * from table order by key_part1 desc ,key_part2 desc

以下不会用到索引

select * from table order by key1 desc , key2 asc --混用desc asc
select * from table where key2=constant order by key1  --where 条件关键字和order by 关键字不同
select * from table order by  key1 ,key2 --order by 使用不同的关键字

Filesort优化

某些情况下还是无法避免Filesort ，所以要加快Filesort操作。Mysql有两种排序算法，

  1. 两次扫扫描算法，

    首先是取出需要的字段和行指针信息，之后再sort_buffer中就进行排序，如果sort buffer 不够就使用临时表存储中进行排序，完成排序后在使用行指针回表查询数据，需要两次访问数据，第一次排序字段和获取行指针信心，第二次，需要那行信息回表查询记录，缺点是需要多次IO操作，优点内存消耗少

  2. 一次扫描算法

    一次性取出满足条件的左右字段，在sor buffer中进行排序，直接返回结果，缺点内存消耗大，优点，排序效率高，

mysql是使用系统变量max_length_for_sort_data的大小和query语句的字段总大小判断使用哪一种算法，如果max_length_for_sort_data更大，使用第二种优化之后算法，否则使用第一种算法。

适当的时候可以增加max_length_for_sort_data，能够让mysql选择更优化的算法，也可以适当的加大sort_buffer_size排序区，尽可能的在内存中进行排序，而不是通过临时表进行排序，max_length_for_data和sort_buffer_size都不能设置过大，否则会带来其他问题。也查询的的时候，尽量select 具体的字段，不要使用select *.

优化group by

默认情况下，mysql对group by col1,col2 字段进行排序，这与order by col1 col2类似，如果显式的堆一个包含相同列的order by 子句，实际上没有什么影响，如果查询group by 但是用户想要避免不必要的排序，则可以指定order by null.

优化分页查询

一般查询是，通过创建覆盖索引能够比较好的提高性能，一个常见的问题就是limit 1000,20 查询出1020行，但是返回的是1000到1020条数据，其他数据都进行抛弃了

1.使用主键回表查询原表的记录,下面我们发现直接查询是进行全表查询，而使用主键关联回表查询可以提高查询效率

mysql> explain select  film_id, description from film order by title limit 50,5 \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: film
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1000
        Extra: Using filesort
1 row in set (0.00 sec)

mysql> explain select a.film_id,a.description from film a inner join (select film_id from film order by title limit 50,5) b on a.film_id=b.film_id \G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 55
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: PRIMARY
        table: a
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 2
          ref: b.film_id
         rows: 1
        Extra: NULL
*************************** 3. row ***************************
           id: 2
  select_type: DERIVED
        table: film
         type: index
possible_keys: NULL
          key: idx_title
      key_len: 767
          ref: NULL
         rows: 1000
        Extra: Using index
3 rows in set (0.00 sec)

2.记录上一次的某个位置，用记录上一页的最后一行的字段，在使用limit n ,

mysql> explain select  *  from payment where rental_id<15640 order by rental_id desc limit 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: payment
         type: range
possible_keys: fk_payment_rental
          key: fk_payment_rental
      key_len: 5
          ref: NULL
         rows: 8043
        Extra: Using index condition
1 row in set (0.00 sec)

使用排序rental_id 记录上一页的最后位置，在根据这个位置过滤且使用limit n，可以有效提高查询的效率，但是在rental_id有大量重复的情况下，这种优化会丢失数据。

使用sql 提示

SQL提示也是优化数据库的一种重要手段，就是认为的加入一些提示达到优化的目的。

  1. use index:在查询表明的后面，添加use index 来提供希望mysql参考索引列表，就可以让mysql不在考虑其他可用的索引

  2. ignore index:如果用户想忽略一个或多个索引，可以使用ignore index .

  3. force index :可以使用mysql强制只用某个特定的索引。

 

 

eff666
关注
专栏目录
mysql优化笔记+资料
11-18
以下是一份详细的MySQL优化笔记，涵盖了多个方面： 一、查询优化 1. 使用索引：为经常用于搜索的列创建索引可以显著加快查询速度。B树和哈希索引是最常见的类型，适用于不同的查询场景。 2. 避免全表扫描：尽量使用...
mysql中优化和修复数据库工具mysqlcheck详细介绍
12-15
MySQL中的`mysqlcheck`是一个非常实用的数据库维护工具，主要用于检查、修复、优化以及分析MyISAM表。它提供了一种高效且安全的方式来管理数据库，尤其是当你无法或不想停止MySQL服务器的时候。`mysqlcheck`与`...
mysql优化说明,mysql优化介绍
weixin_31134719的博客
03-17 62
第1章 mysql优化介绍我们优化mysql要把持一个理念 优化是为的业务的持续性 高效性但通常事实告诉我们 结果与其期待往往相反 (优化后更慢了)优化有风险 涉足需谨慎1.1 优化的风险优化不是单纯的对一个数据库进行优化 可能是一个复杂的已投产的环境进行优化优化手段本来就有很大的风险，只不过你没能力意识到和预见到！任何的技术可以解决一个问题，但必然存在带来一个问题的风险！对于优化来说解决问...
MySQL主要优化手段(数据读写分离、Sharding)介绍
20Hui的博客
09-19 867
MySQL常用优化手段：数据读写分离与数据库Sharding 数据读写分离 在大多数的业务场景，都是读多写少，因此进行数据库的读写分离是一件非常简单且有效率的方案。 读写分离简单点来说就是把数据的读操作和写操作分开，让这两种操作去访问不同的数据库，这样就可以减轻数据库的压力 从阿里云的读写分离可以看出数据库会有一个“主实例”，这个主要用来提供写操作(偶尔也会承担读操作)，除了“主实例”...
mysql性能优化介绍
beyond的博客
11-18 319
mysql性能优化前言1 MySql架构与存储引擎2.业务设计3.查询以及索引 前言 分三个方面和大家介绍下实际工作中如何对mysql进行优化 衡量指标 TPS：Transactions Per Second（每秒传输的事物处理个数），这是指服务器每秒处理的事务数，支持事务的存储引擎如InnoDB等特有的一个性能指标。 QPS：Queries Per Second（每秒查询处理量）同时适用与Inn...
【MySQL】性能优化介绍
咔咔博客
08-02 537
在对于mysql的性能优化上，在以前估计考虑的太片面了，今天在别的的地方搜集了一些材料，仅供参考 性能优化介绍 优化没有固定的代码格式，也没有固定的操作方案，一切都是对待当下的问题，进行处理 对于用户来说：‘又卡了，怎么死机了，反应太慢了’ 对于我们来说，程序执行时间太长了，每秒查询的次数，内存，cpu的利用率 程序优化的目的 合理的利用可利用的资源（技术能处理的，何必花费冤枉钱） 吞吐量:越...
mysql的性能优化介绍(一)
sinat_30594513的博客
03-23 325
首先我们关注一下MySQL的总体的架构 细说SQL LAYER 思想的逻辑类似于我们的写的server服务，其实他就是一个MySQL的server服务 比较关注的点是： 1.我们的查询缓存模块：当我的查询在查询缓存模块已经获取到数据的时候，我们就不会进行下面的流程了，我的可以设置查询缓存模块的大小 我们关注的存储引擎 无论是关系型数据库，还是No SQL它底层存储的数据都是文件 在MySQL里...
MySQL索引性能优化分析
热门推荐
张彦峰的博客
04-07 173万+
总结MySQL索引性能优化，主要集中在索引的背景介绍以及索引的高效创建、使用和查询等，最有给出除了索引的一些其他优化思路
MySQL之优化SELECT语句
沉淀、分享、成长，让自己和他人都能有所收获！
07-31 2万+
本文主题为MySQL优化SELECT语句，涵盖了数据库性能提升概述，WHERE子句优化，范围优化和哈希联接优化。在数据库性能方面，需要考虑软件结构、CPU和I/O操作的最小化和高效执行。WHERE子句优化涉及改进查询的算法和可读性。范围优化介绍了优化器使用范围访问方法的条件和方法。哈希联接优化方面，MySQL在较新版本中使用哈希连接取代了块嵌套循环联接算法，从而提高查询速度。
mysql 相关介绍以及优化
11-06
mysql 相关介绍以及优化 MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是最流行的开源关系数据库管理系统之一，广泛应用于 Web 应用程序中。 MySQL 是一个多线程的...
mysql优化之参数精彩介绍
zhang5207892的博客
01-26 304
对性能影响非常大的是数据库结构设计和mysql语句的优化,优先从这两点开始优化,一般情况下,我们对mysql结构和语句优化做到非常好了情况下,可以考虑如下对mysql参数进行配置优化。 innodb I/O相关配置 若出现宕机，可以通过事务日志恢复数据 Innodb_log_file_size控制了单个事务日志的大小 Innodb_log_filesin_group控制着事务日志的个数
基于SpringBoot+Vue+MySQL的养老院管理系统
程序员大金的博客
09-20 770
基于SpringBoot+Vue+MySQL的养老院管理系统，附源码。
mysql的查询操作
最新发布
weixin_45710581的博客
09-24 495
MySQL的查询操作是数据库管理和数据检索的核心。通过SQL（Structured Query Language，结构化查询语言）语句，用户可以执行包括数据检索、数据插入、更新和删除在内的多种操作。在本文中，我们将重点讨论数据检索（即SELECT语句）的高级用法和最佳实践。
【实战篇】MySQL是怎么保证高可用的？
shenyongsi的博客
09-20 994
在一个主备关系中，每个备库接收主库的 binlog 并执行。正常情况下，只要主库执行更新生成的所有 binlog，都可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。但是，MySQL 要提供高可用能力，只有最终一致性是不够的。主备切换可能是一个主动运维动作，比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电。我们先说明一个概念，即“同步延迟”。所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。
Web+Mysql——MyBatis
qq_73643693的博客
09-20 1447
MyBatis 是一款优秀的持久层框架，用于简化 JDBC 开发MyBatis 本是 Apache 的一个开源项目iBatis, 2010年这个项目由apache software foundation 迁移到了google code，并且改名为MyBatis。2013年11月迁移到Github官网：https://mybatis.org/mybatis-3/zh/index.html负责将数据到保存到数据库的那一层代码。以后开发我们会将操作数据库的Java代码作为持久层。
【编程底层原理】mysql的redo log undo log bin log日志的作用，以及何时生成，涉及到哪些参数变量
Dylaniou的博客
09-20 485
这些日志共同工作，确保了MySQL数据库的稳定性和数据的一致性。Redo log和undo log是InnoDB存储引擎特有的日志，而binlog则是MySQL服务器层的日志，它们之间的区别主要在于作用、生成时机和适用对象。
mysql 重置密码
sszdzq的博客
09-19 472
mysql 重置密码
MySQL性能优化与基础介绍
"MySQL性能优化涉及对查询速度、更新速度以及服务器本身的优化，旨在提高运行效率，减少资源消耗。MySQL是流行的开源数据库系统，因其高效、简单和可靠的特点被广泛应用。" MySQL作为世界上最受欢迎的开源数据库之...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值