Merge branch 'master' of github.com:fengzhao/mysql-wiki

fengzhao · Jul 8, 2024 · fefbbd0 · fefbbd0
2 parents 7fe06e6 + 6fedb44
commit fefbbd0
Show file tree

Hide file tree

Showing 4 changed files with 30 additions and 8 deletions.
diff --git a/docs/basic/12.MySQL内存概述.md b/docs/basic/12.MySQL内存概述.md
@@ -1,6 +1,17 @@
 # 内存概述
 
 
+MySQL分配缓冲区和缓存以提高数据库操作的性能。默认配置旨在允许MySQL服务器在具有大约512MB RAM的虚拟机上启动。您可以通过增加某些缓存和缓冲区相关系统变量的值来提高 MySQL 性能。您还可以修改默认配置以在内存有限的系统上运行 MySQL。
+
+MySQL以两种方式使用内存：
+
+1、永久保留供其使用的内存 – 此类称为"全局缓冲区"的内存在服务器启动期间从操作系统获取，不会释放到任何其他进程。
+
+2、根据请求动态请求的内存 – MySQL使用"线程缓冲区"，这是在处理新查询时从操作系统请求的内存。执行查询后，此内存将释放回操作系统。
+
+因此，您可以说MySQL的内存使用量是"全局缓冲区+（线程缓冲区x允许的最大连接数）"。
+
+
 
 内存是重要的性能参数，常常出现由于异常的 SQL 请求以及待优化的数据库导致内存利用率升高的情况，严重时还会出现由于 OOM 导致实例发生 HA 切换的情况。
 

diff --git a/docs/basic/9.mysql_architecture.md b/docs/basic/9.mysql_architecture.md
@@ -410,17 +410,26 @@ show global status;
 
 #### 线程缓存
 
-线程缓存实现在MySQL server端，client连接之后对应的sql线程在服务端会被缓存起来，缓存的线程数量由 [thread_cache_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_thread_cache_size) 大小决定。
+线程缓存实现在`MySQL server`端。当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户端的连接（而不是直接销毁线程，当然前提是缓存数未达上限）。
+
+缓存的线程数量由 [thread_cache_size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_thread_cache_size) 大小决定。
 
 当服务器不断有大量连接创建、关闭的场景下，使用线程缓存能够重用缓存起来的线程，避免了大量连接线程的反复创建销毁带来的CPU上下文切换性能消耗，但是仍然无法解决高连接数带来的线程数过高的问题。
 
+
+如果是短连接，适当设置大一点。因为短连接往往需要不停创建，不停销毁，如果大一点，连接线程都处于取用状态，不需要重新创建和销毁，所以对性能肯定是比较大的提升。
+对
+于长连接，不能保证连接的稳定性，所以设置这参数还是有一定必要，可能连接池的问题，会导致连接数据库的不稳定性，也会出现频繁的创建和销毁，但这个情况比较少，如果是长连接，可以设置成小一点，一般在50-100左右。
+
+
 ```shell
 # 查看线程缓存大小
 show global variables like 'thread_cache_size';
 
 
 # thread_stack: 每个连接线程被创建时，MySQL给它分配的内存大小。当MySQL创建一个新的连接线程时，需要给它分配一定大小的内存堆栈空间，以便存放客户端的请求的Query及自身的各种状态和处理信息。
-# Thread Stack默认值（192KB）足够正常运行。如果线程堆栈大小太小，则会限制服务器可以处理的SQL语句的复杂性，存储过程的递归深度以及其他消耗内存的操作。一般情况下都能正常使用，但是当查询语句或者存储过程复杂时会报Threadstack overrun（超限）错误，此时只要修改增加默认配置就可以了
+# Thread Stack 默认值（192KB）足够正常运行。如果线程堆栈大小太小，则会限制服务器可以处理的SQL语句的复杂性，存储过程的递归深度以及其他消耗内存的操作。
+# 一般情况下都能正常使用，但是当查询语句或者存储过程复杂时会报Threadstack overrun（超限）错误，此时只要修改增加默认配置就可以了
 show VARIABLES like 'thread_stack'
 
 # 系统启动到现在共接受到客户端的连接次数
@@ -434,7 +443,7 @@ show global status like 'Threads_%';
 | 配置              | 含义                                                         |
 | ----------------- | ------------------------------------------------------------ |
 | Threads_cached    | 状态变量：当前线程池中缓存有多少空闲线程                     |
-| Threads_connected | 状态变量：当前的连接数 ( 也就是线程数 )                      |
+| Threads_connected | 状态变量：当前的连接数 ( 因为一个连接就需要一个线程，所以也可以看成当前被使用的线程数 )                      |
 | Threads_created   | 状态变量：开启以来累计已经创建过的线程总数                                 |
 | Threads_running   | 状态变量：当前激活的线程数 ( Threads_connected 中的线程有些可能处于休眠状态 ) |
 

diff --git a/docs/foundmental/suoyin.md b/docs/foundmental/suoyin.md
@@ -1173,13 +1173,16 @@ CREATE TABLE `geek` (
 
 所谓的索引有效，是指**使用了索引的快速搜索功能，并且有效的减少了扫描行**，所以**全索引扫描**（辅助索引树）和**全表扫描**（主键索引树）都不能称为真正的**索引有效**
 
+ 对于复合索引 Index（A,B），B 树的排序是按 A 列的数值为第一要素，B 列的数值为第二要素进行排序，这也就是为什么我们查询语句时，条件语句必须保证最左原则才可以利用到索引
 
 谈到联合索引，一定要讲**最左前缀匹配**，有如下原则：
 
 - **如果查询的时候查询条件可以通过索引精确匹配左边连续一列或几列，则此列就可以被用到**。
 
 - 注意，一定要是指精准匹配。
 
+
+
 ```sql
 CREATE TABLE test (
 	id INT NOT NULL,

diff --git a/docs/optimize/1.overview.md b/docs/optimize/1.overview.md
@@ -174,10 +174,9 @@ TPC-C使用tpmC值（Transactions per Minute）来衡量系统最大有效吞吐
 
 
 
-**基准测试的性能指标**
+#### 基准测试的性能指标
 
-在衡量一个系统性能时，一定要有可量化的指标，无法量化就无法有效的优化系统性能。
-系统每秒可以承载多大请求量，每个请求的响应时间，并发数等都是衡量一个系统的关键性能指标。
+在衡量一个系统性能时，一定要有可量化的指标，无法量化就无法有效的优化系统性能。系统每秒可以承载多大请求量，每个请求的响应时间，并发数等都是衡量一个系统的关键性能指标。
 
 
 **吞吐量-Throughput**
@@ -187,9 +186,9 @@ TPC-C使用tpmC值（Transactions per Minute）来衡量系统最大有效吞吐
 
 吞吐量常用的计量单位：
 
-- 每秒事务数（TPS）
+- 每秒事务数（TPS Transactions Per Second）
 
-- 每秒查询数（QPS） ，每秒能够响应的查询次数。
+- 每秒查询数（QPS Query Per Second） ，每秒能够响应的查询次数。
 
 比如，对于Web服务器，用户对某一个页面的一次请求，用户对某系统的一次登录，用户对商品的一次确认支付过程；
 对于数据库，一次查询、修改、新增、删除。这些我们都可以看作一个事务或者请求。