MySQL优化之慢查询日志
慢查询日志概述
所谓慢查询日志，就是用于记录MySQL中响应时间超过设定阈值的SQL语句，通过打开慢查询开关，MySQL会将大于阈值的SQL记录在日志中，以便于分析性能。
慢查询日志选项默认是关闭的，如果要开启，则需要手动设置。
慢查询日志选项不建议一直开启，因为记录日志意味着IO操作，本身对性能有一定的影响，因此，建议在生产环境关闭该选项；而在开发环境调优阶段可以适当打开该选项。
检查是否开启了慢查询日志：
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /var/lib/mysql/DESKTOP-Q5J25HR-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.03 sec)
slow_query_log选项即开启慢查询的开关，OFF为关闭，ON为开启。
slow_query_log_file即慢查询日志的名称。
如果要开启慢查询日志，则执行如下语句：
set global slow_query_log = ON;
/* 或者 */
set global slow_query_log = 1;
以上两句话是一个意思，执行任意一条都可以。执行完毕，再次查询，已经打开。
mysql> set global slow_query_log = ON;
Query OK, 0 rows affected (0.05 sec)
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/DESKTOP-Q5J25HR-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.00 sec)
同样的，慢查询日志的文件名也可以重新指定，只需要设置set global slow_query_log_file = 文件名即可。
前面说过，慢查询日志只有当SQL语句响应时间超过一定阈值才会记录在日志中，那么这个阈值是多少，该如何设置呢？
可通过以下命令查看慢查询日志的阈值：
mysql> show variables like '%long_query_time%';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
可以看到，默认的阈值是10秒，该值同样可以通过设置来修改，如设置为0.1秒：
set global long_query_time = 0.1;
long_query_time设置完成后，需要退出MySQL客户端，重新登录后才生效，于是可以看到该值已经变成了0.1：
mysql> show variables like '%long_query_time%';
+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| long_query_time | 0.100000 |
+-----------------+----------+
1 row in set (0.01 sec)
慢查询日志具体案例
接下来通过案例的方式来演示慢查询日志：
我在当前数据库里有一张test01表，表结构如下所示：
mysql> desc test01;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| id | int(4) | YES | MUL | NULL | |
| name | varchar(20) | YES | | NULL | |
| passwd | char(20) | YES | | NULL | |
| inf | char(50) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
4 rows in set (0.04 sec)
分别做如下查询：
select * from test01;
select sleep(1);
select id, sleep(2) from test01;
执行结果如下所示：
mysql> select * from test01;
+------+------+--------+--------+
| id | name | passwd | inf |
+------+------+--------+--------+
| 1 | zz | 123456 | asdfgh |
+------+------+--------+--------+
1 row in set (0.00 sec)
mysql> select sleep(1);
+----------+
| sleep(1) |
+----------+
| 0 |
+----------+
1 row in set (1.00 sec)
mysql> select id, sleep(2) from test01;
+------+----------+
| id | sleep(2) |
+------+----------+
| 1 | 0 |
+------+----------+
1 row in set (2.00 sec)
此时并需要去不关心SQL本身，而是看这三条SQL执行的时间，从上面可以看到，第一条SQL执行几乎不耗时间，显示0.00 sec，第二条SQL显示时间为 1.00 sec，第三条SQL为 2.00 sec。
因为我们设置了阈值为0.1秒，因此后两条SQL应该都要记录在慢查询日志中，接下来验证是否如此：
通过如下命令，可查看慢查询SQL的条数：
mysql> show global status like '%slow_queries%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries | 2 |
+---------------+-------+
1 row in set (0.02 sec)
显示记录为2条，与实际情况一致。
通过show variables like '%slow_query_log%'命令，可以查看到日志的具体路径。
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/DESKTOP-Q5J25HR-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.00 sec)
打开/var/lib/mysql/DESKTOP-Q5J25HR-slow.log，可以看到日志当中记录了时间超过阈值的那两条SQL语句：
/usr/sbin/mysqld, Version: 5.7.29-0ubuntu0.18.04.1 ((Ubuntu)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
/usr/sbin/mysqld, Version: 5.7.29-0ubuntu0.18.04.1 ((Ubuntu)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
# Time: 2020-03-31T13:41:25.726554Z
# User@Host: root[root] @ localhost [] Id: 6
# Query_time: 1.000644 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 0
use testDB;
SET timestamp=1585662085;
select sleep(1);
# Time: 2020-03-31T13:41:34.246770Z
# User@Host: root[root] @ localhost [] Id: 6
# Query_time: 2.000536 Lock_time: 0.000057 Rows_sent: 1 Rows_examined: 1
SET timestamp=1585662094;
select id, sleep(2) from test01;
mysqldumpslow工具
以上介绍的方法虽然可以查看出所有慢SQL语句，但显然都记录在一个日志文件里，会显得很乱，而且一旦SQL比较多，定位起来还是比较麻烦的。
好在MySQL本身提供了一个专门用来查看慢查询日志的工具，即mysqldumpslow。
可通过MySQLdumpslow -help查看具体使用方法：
chenyc@DESKTOP-Q5J25HR:~$ mysqldumpslow -help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]
Parse and summarize the MySQL slow query log. Options are
--verbose verbose
--debug debug
--help write this text to standard output
-v verbose
-d debug
-s ORDER what to sort by (al, at, ar, c, l, r, t), 'at' is default
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time
-r reverse the sort order (largest last instead of first)
-t NUM just show the top n queries
-a don't abstract all numbers to N and strings to 'S'
-n NUM abstract numbers with at least n digits within names
-g PATTERN grep: only consider stmts that include this string
-h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard),
default is '*', i.e. match all
-i NAME name of server instance (if using mysql.server startup script)
-l don't subtract lock time from total time
从以上文件中，可以知道，该工具用法如下：
mysqldumpslow [选项] [日志名]
常用选项说明：
- -s 即order排序,后面可以有以下选项：
- al 平均锁定时间
- ar 平均返回记录时间
- at 平均查询时间
- c 计数
- l 锁定时间
- r 逆序排序
- t 查询时间
- -t，相当于top n，即返回前面n条语句
- -g， 匹配正则表达式，大小写不敏感
如：
sudo mysqldumpslow -s r -t 3 -g 'select' /var/lib/mysql/DESKTOP-Q5J25HR-slow.log
以上命令表示：返回按逆序排序的其中三条语句，且语句中包含select的SQL语句。
结果如下所示：
chenyc@DESKTOP-Q5J25HR:~$ sudo mysqldumpslow -s r -t 3 -g 'select' /var/lib/mysql/DESKTOP-Q5J25HR-slow.log
Reading mysql slow query log from /var/lib/mysql/DESKTOP-Q5J25HR-slow.log
Count: 1 Time=2.00s (2s) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
select id, sleep(N) from test01
Count: 1 Time=1.00s (1s) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
select sleep(N)
Died at /usr/bin/mysqldumpslow line 167, <> chunk 2.
Profiles工具
profiles最大的作用是用来分析海量数据，该命令会记录所有执行过的SQL语句。
这个选项默认也是关闭的，需要手动打开。
查询profiles选项命令：
mysql> show variables like '%profiling%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| have_profiling | YES |
| profiling | OFF |
| profiling_history_size | 15 |
+------------------------+-------+
3 rows in set (0.01 sec)
打开命令：
mysql> set profiling = ON;
Query OK, 0 rows affected, 1 warning (0.00 sec)
再次查看，可以换一种方式查看：
mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
| 1 |
+-------------+
1 row in set, 1 warning (0.00 sec)
以上选项，1代表打开，0代表关闭。
为了更为直观的查看profile，我们再执行两条SQL：
mysql> select sleep(3);
+----------+
| sleep(3) |
+----------+
| 0 |
+----------+
1 row in set (3.00 sec)
mysql> select * from test01;
+------+------+--------+--------+
| id | name | passwd | inf |
+------+------+--------+--------+
| 1 | zz | 123456 | asdfgh |
+------+------+--------+--------+
1 row in set (0.00 sec)
好了，准备工作就到这里，现在来查看profile：
mysql> show profiles;
+----------+------------+-----------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------+
| 1 | 0.00214400 | show variables like '%profiling%' |
| 2 | 0.00017400 | select @@profiling |
| 3 | 3.00062925 | select sleep(3) |
| 4 | 0.00023450 | select * from test01 |
+----------+------------+-----------------------------------+
4 rows in set, 1 warning (0.00 sec)
如上所示，它会记录所有的语句，其中第二列Duration代表的是执行时间。
以上虽然可以看到每条SQL的执行时间，但我们无法精确知道有多少时间花费在IO上，多少时间花费在CPU上，因此，还可使用以下语句查看更为精确的内容：
show profile all for query $(Query_ID);
上面的Query_ID即show profiles结果中第一列的id编号。如：
mysql> show profile all for query 4;
+----------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
| Status | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Messages_sent | Messages_received | Page_faults_major | Page_faults_minor | Swaps | Source_function | Source_file
| Source_line |
+----------------------+----------+----------+------------+-------------------+---------------------+--------------+---------------+---------------+-------------------+-------------------+-------------------+-------+-----------------------+----------------------+-------------+
| starting | 0.000045 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | NULL | NULL
| NULL |
| checking permissions | 0.000008 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | check_access | sql_authorization.cc | 809 |
| Opening tables | 0.000020 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | open_tables | sql_base.cc
| 5781 |
| init | 0.000017 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | handle_query | sql_select.cc
| 128 |
| System lock | 0.000016 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 2 | 0 | mysql_lock_tables | lock.cc
| 330 |
| optimizing | 0.000005 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc
| 158 |
| statistics | 0.000014 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc
| 374 |
| preparing | 0.000010 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | optimize | sql_optimizer.cc
| 482 |
| executing | 0.000004 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | exec | sql_executor.cc
| 126 |
| Sending data | 0.000051 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 8 | 0 | exec | sql_executor.cc
| 202 |
| end | 0.000005 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | handle_query | sql_select.cc
| 206 |
| query end | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc
| 4956 |
| closing tables | 0.000007 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | mysql_execute_command | sql_parse.cc
| 5009 |
| freeing items | 0.000013 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | mysql_parse | sql_parse.cc
| 5622 |
| cleaning up | 0.000013 | 0.000000 | 0.000000 | 0 | 0 | 0 |
0 | 0 | 0 | 0 | 0 | 0 | dispatch_command | sql_parse.cc
| 1931 |
+----------------------+----------+----------+------------+-------------------+---------------------+--------------+-------------
--+---------------+-------------------+-------------------+-------------------+-------+-----------------------+------------------
----+-------------+
15 rows in set, 1 warning (0.00 sec)
上面的结果由于选项太多，看起来还是有些乱，其实很多东西我们并不关注，而主要只关注CPU和IO情况，因此，可以进一步简化如下：
mysql> show profile cpu, block io for query 4;
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| starting | 0.000045 | 0.000000 | 0.000000 | 0 | 0 |
| checking permissions | 0.000008 | 0.000000 | 0.000000 | 0 | 0 |
| Opening tables | 0.000020 | 0.000000 | 0.000000 | 0 | 0 |
| init | 0.000017 | 0.000000 | 0.000000 | 0 | 0 |
| System lock | 0.000016 | 0.000000 | 0.000000 | 0 | 0 |
| optimizing | 0.000005 | 0.000000 | 0.000000 | 0 | 0 |
| statistics | 0.000014 | 0.000000 | 0.000000 | 0 | 0 |
| preparing | 0.000010 | 0.000000 | 0.000000 | 0 | 0 |
| executing | 0.000004 | 0.000000 | 0.000000 | 0 | 0 |
| Sending data | 0.000051 | 0.000000 | 0.000000 | 0 | 0 |
| end | 0.000005 | 0.000000 | 0.000000 | 0 | 0 |
| query end | 0.000007 | 0.000000 | 0.000000 | 0 | 0 |
| closing tables | 0.000007 | 0.000000 | 0.000000 | 0 | 0 |
| freeing items | 0.000013 | 0.000000 | 0.000000 | 0 | 0 |
| cleaning up | 0.000013 | 0.000000 | 0.000000 | 0 | 0 |
+----------------------+----------+----------+------------+--------------+---------------+
15 rows in set, 1 warning (0.00 sec)
全局查询日志
同profiles一样，打开全局查询日志选项以后，它会记录下所有SQL语句，但是由于该操作比较耗费性能，因此，只建议在开发环境临时打开该选项。
查看全局查询日志命令：
mysql> show variables like '%general_log%';
+------------------+------------------------------------+
| Variable_name | Value |
+------------------+------------------------------------+
| general_log | OFF |
| general_log_file | /var/lib/mysql/DESKTOP-Q5J25HR.log |
+------------------+------------------------------------+
2 rows in set (0.01 sec)
打开全局查询日志选项：
set global general_log = on;
再次查询：
mysql> show variables like '%general_log%';
+------------------+------------------------------------+
| Variable_name | Value |
+------------------+------------------------------------+
| general_log | ON |
| general_log_file | /var/lib/mysql/DESKTOP-Q5J25HR.log |
+------------------+------------------------------------+
2 rows in set (0.00 sec)
设置完以上之后，还需要做如下设置：
set global log_output = 'table';
同样的，准备以下SQL：
select * from test01;
select id, name from test01 where id = 1;
全局查询日志记录在mysql.general_log表中。
mysql> select * from mysql.general_log;
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------------------+
| event_time | user_host | thread_id | server_id | command_type | argument
|
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------------------+
| 2020-03-31 22:31:24.750895 | root[root] @ localhost [] | 6 | 0 | Query | select * from test01
|
| 2020-03-31 22:31:26.128924 | root[root] @ localhost [] | 6 | 0 | Query | select id, name from test01 whe
re id = 1 |
| 2020-03-31 22:32:15.736558 | root[root] @ localhost [] | 6 | 0 | Query | select * from mysql.general_log
|
+----------------------------+---------------------------+-----------+-----------+--------------+--------------------------------
----------+
3 rows in set (0.01 sec)
既然有记录到表中，自然也有记录到文件中，只需要做如下设置：
set global general_log_file = '/tmp/mysql_general.log'; --设置文件路径
set global log_output = 'file'; --设置记录到文件
可通过如下命令查看文件路径：
mysql> show variables like '%general_log%';
+------------------+------------------------+
| Variable_name | Value |
+------------------+------------------------+
| general_log | ON |
| general_log_file | /tmp/mysql_general.log |
+------------------+------------------------+
2 rows in set (0.00 sec)
同样执行以上两条SQL：
select * from test01;
select id, name from test01 where id = 1;
查看文件内容，得到如下结果：
chenyc@DESKTOP-Q5J25HR:~$ sudo cat /tmp/mysql_general.log
/usr/sbin/mysqld, Version: 5.7.29-0ubuntu0.18.04.1 ((Ubuntu)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
2020-03-31T14:35:49.793176Z 6 Query show variables like '%general_log%'
2020-03-31T14:37:20.241374Z 6 Query select * from test01
2020-03-31T14:37:21.408617Z 6 Query select id, name from test01 where id = 1
MySQL优化之慢查询日志的更多相关文章
- Mysql优化_慢查询开启说明及Mysql慢查询分析工具mysqldumpslow用法讲解
Mysql优化_慢查询开启说明及Mysql慢查询分析工具mysqldumpslow用法讲解 Mysql慢查询开启 Mysql的查询讯日志是Mysql提供的一种日志记录,它用来记录在Mysql中响应 ...
- mysql 优化2 慢查询
默认情况下mysql不记录慢查询日志,需要在启动的时候指定 bin\mysqld.exe - -slow-query-log 通过慢查询日志定位执行效率较低的SQL语句.慢查询日志记录了所有执行时间超 ...
- SQL语句技巧_索引的优化_慢查询日志开启_root密码的破解
1.正则表达式的使用 regexp例:select name,email from t where email regexp '@163[.,]com$'使用like方式查询selct name,em ...
- mysql优化：慢查询分析、索引配置优化
一.优化概述二.查询与索引优化分析a.性能瓶颈定位show命令慢查询日志explain分析查询profiling分析查询b.索引及查询优化三.配置优化 max_connections back_log ...
- Mysql 优化，慢查询
最近项目上遇到点问题,服务器出现连接超时.上次也是超时,问题定位到mongodb上,那次我修改好了,这次发现应该不是这个的问题了. 初步怀疑是mysql这边出问题了,写的sql没经过压力测试,导致用户 ...
- mysql中的慢查询日志
首先我们看一下关于mysql中的日志,主要包含:错误日志.查询日志.慢查询日志.事务日志.二进制日志: 日志是mysql数据库的重要组成部分.日志文件中记录着mysql数据库运行期间发生的变化:也就是 ...
- Mysql优化系列之查询性能优化前篇1
前言 这是优化系列的最后一篇的第1小篇,我们其实可以直接从sql怎么写讲起,why not?但是我还是决定花2个篇幅 问一些问题,带着几个问题循序渐进的往下走. 一个sql语句是怎么被执行的? sql ...
- MySQL 5.7 启用查询日志
MySQL版本:5.7 新版本的 my.ini 文件改动了,导致原先启用查询日志的方法不再适用 新版本的启用方法如下: 1. 修改 C:\ProgramData\MySQL\MySQL Server ...
- Mysql优化之Explain查询计划查看
我们经常说到mysql优化,优化中一种常见的方式就是对于经常查询的字段创建索引.那么mysql中有哪些索引类型呢? 一.索引分类1.普通索引:即一个索引只包含单个列,一个表可以有多个单列索引 2.唯一 ...
随机推荐
- History of AI
人工智能的历史源远流长.在古代的神话传说中,技艺高超的工匠可以制作人造人,并为其赋予智能或意识.[1]现代意义上的AI始于古典哲学家用机械符号处理的观点解释人类思考过程的尝试.20世纪40年代基于抽象 ...
- Spark OFF_HEP变迁
在文章的开头,安利一下我自己的github上的一个项目:AlluxioBlockManager,同时还有我的github上的博客:blog这个项目的作用是替代Spark2.0以前默认的TachyonB ...
- Snap们崛起告诉我们：这个世界太需要悄悄话
北京时间3月3日凌晨,"阅后即焚"应用Snapchat母公司Snap在纽约证券交易所上市.开盘价24美元,比其初定的17美元IPO价格高出近41.2%,按照24美元的股价计算, ...
- Spring Boot 2.x基础教程：使用 Thymeleaf开发Web页面
通过本系列教程的前几章内容(API开发.数据访问).我们已经具备完成一个涵盖数据存储.提供HTTP接口的完整后端服务了.依托这些技能,我们已经可以配合前端开发人员,一起来完成一些前后端分离的Web项目 ...
- Spring aop（1）--- 寻找切面和代理对象执行流程源码分析
1.基于注解,首先我们是通过@EnableAspectJAutoProxy()这个注解开起AOP功能,这个注解会导入AspectJAutoProxyRegistrar组件从而将AnnotationAw ...
- 曹工说Spring Boot源码（21）-- 为了让大家理解Spring Aop利器ProxyFactory，我已经拼了
写在前面的话 相关背景及资源: 曹工说Spring Boot源码(1)-- Bean Definition到底是什么,附spring思维导图分享 曹工说Spring Boot源码(2)-- Bean ...
- Java并发ReentrantLock
ReentrantLock简介 可重入锁,作用是使线程安全.对比于sychronized,它能具有以下特点 减小资源锁的力度 更可控,减少发生死锁的概率 加锁.释放锁都是显示控制的 添加锁的作用时间来 ...
- 前端每日实战：131# 视频演示如何用纯 CSS 创作一把剪刀
效果预览 按下右侧的"点击预览"按钮可以在当前页面预览,点击链接可以全屏预览. https://codepen.io/comehope/pen/GXyGpZ 可交互视频 此视频是可 ...
- 修复Nginx的WebDAV功能
如果想使用WebDAV来实现文件共享,尤其是想使用操作系统内置功能来挂载文件系统的话,省心的话还是用Apache吧. 下文介绍如何用Nginx来实现这个目标.Windows内置的客户端是Microso ...
- ElementUI el-table 在flex下的宽度自适应问题
BUG:在flex容器下面的一个flex:1的子容器里面写了个el-table用来展示列表数据,在做宽度自适应测试的时候发现该组件的宽度只会增加不会缩小. Debug:通过控制台发现组件生成的tabl ...