小白学习MySQL - MySQL会不会受到“高水位”的影响？
2024-06-17 14:27:42
前两天碰到了一个问题，MySQL的一张表，1220万数据量，需要删除1200万数据，仅存储20万数据，讨论了三种方案，
1. 00:00直接执行truncate，只存储新数据。
2. 将1220万中的20万采用CTAS存到一张中间表，再通过rename改这两张表的名称，实现替换操作。
3. delete删除1200万数据。
经过综合考虑，用的方案3，方案选择的过程，不多说了，我们就来说下delete删除数据的问题。
如果按照Oracle的思维，堆表是存在高水位这个问题的，High-warter mark, HWM，存储空间就像水库一样，数据就像水库中的水，水的位置是存在一条线的，这就是水位线，在数据库表刚建立的时候，由于没有任何数据，所以这个时候水位线是空的，就是说HWM为最低值，当插入了数据以后，高水位线就会上涨。这里有个特性，如果采用delete语句删除数据，数据虽然被删除了，但是高水位线却没有降低，还是刚才删除数据以前那么高的水位，就是说这条高水位线在日常的增删操作中只会上涨，不会下降，
P.S. 准确地说在自动段空间管理(ASSM)下存在Low HWM和HWM两种水位线。
高水位线影响最显著的就是全表扫描的效率，因为当进行全表扫描时，会扫描高水位线以下的所有数据块，用上述的例子说，如果1220万数据，删除了1200万，只剩下20万，当进行全表扫描的时候，不会只扫描这20万数据的数据块，他还会扫描1220万数据的数据块。
数据删除了，效率没提高，你说气人不气人？
如果是OLTP的系统，要尽量避免全表扫描，通过索引，绕开高水位线带来的问题。
回到今天的主题，Oracle中的高水位，在MySQL中究竟存在不存在？
以前没碰到过，以为是和Oracle一样的现象，但这次让我知道，两者还是存在一些差异的。
首先，我们从实验开始，MySQL下创建测试表，此时数据为空，
mysql> create table test_delete (-> id int not null,-> col varchar(60) not null,-> primary key(id)-> );
Query OK, 0 rows affected (0.02 sec)
数据表相关信息都是0，
mysql> select table_schema, table_name, ENGINE, round(DATA_LENGTH/1024/1024+ INDEX_LENGTH/1024/1024) total_mb,TABLE_ROWS, round(DATA_LENGTH/1024/1024) data_mb, round(INDEX_LENGTH/1024/1024) index_mb, round(DATA_FREE/1024/1024) free_mb, round(DATA_FREE/DATA_LENGTH*100,2) free_ratio from information_schema.TABLES where TABLE_SCHEMA='bisal' and TABLE_NAME='test_delete';
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| table_schema | table_name | ENGINE | total_mb | TABLE_ROWS | data_mb | index_mb | free_mb | free_ratio |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| bisal | test_delete | InnoDB | 0 | 0 | 0 | 0 | 0 | 0.00 |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
1 row in set (0.00 sec)
Oralce中普通的表都是堆表，而MySQL的InnoDB存储引擎的表都是根据主键顺序组织存放的，又称为“索引组织表”，数据即索引，索引即数据。
利用姜老师提供的工具，看下初始化的数据表文件信息(test_delete.ibd)，B-tree Node作为B树节点，同时也是数据页，
[mysql@bisal py_innodb_page_info-master]$ python py_innodb_page_info.py /mysql/3306/data/bisal/test_delete.ibd -v
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000> //数据页，page level=0，表示他为叶子节点，B+树只有1层，当前无数据
page offset 00000000, page type <Freshly Allocated Page>
page offset 00000000, page type <Freshly Allocated Page>
Total number of page: 6: //总共分配的页数
Freshly Allocated Page: 2 //可用的数据页
Insert Buffer Bitmap: 1 //插入缓冲页
File Space Header: 1 //文件空间头
B-tree Node: 1 //数据页
File Segment inode: 1 //文件端inonde
模拟插入110万数据，select *执行时间是0.27秒，
mysql> select count(*) from test_delete;
+----------+
| count(*) |
+----------+
| 1100000 |
+----------+
1 row in set (0.24 sec)mysql> select * from test_delete where name = 'X';
Empty set (0.27 sec)
数据文件是44M，
-rw-r-----. 1 mysql mysql 8.0K 18 17:46 test_delete.frm
-rw-r-----. 1 mysql mysql 44M 18 18:18 test_delete.ibd根据INNODB_SYS_TABLES和INNODB_SYS_INDEXES，了解到，
(1) TBL_SPACEID是27。
(2) TABLE_ID是43。
(3) INDEX_ID是42。
(4) PAGE_NO是3。
(5) INDEX_TYPE是3。
其中，PAGE_NO=3标识B-tree的root page是3号页，INDEX_TYPE=3是聚集索引，INDEX_TYPE取值如下：
0 = nonunique secondary index;
1 = automatically generated clustered index (GEN_CLUST_INDEX);
2 = unique nonclustered index;
3 = clustered index;
32 = full-text index;
mysql> SELECT A.SPACE AS TBL_SPACEID, A.TABLE_ID, A.NAME AS TABLE_NAME, FILE_FORMAT, ROW_FORMAT, SPACE_TYPE, B.INDEX_ID , B.NAME AS INDEX_NAME, PAGE_NO, B.TYPE AS INDEX_TYPE FROM INNODB_SYS_TABLES A LEFT JOIN INNODB_SYS_INDEXES B ON A.TABLE_ID =B.TABLE_ID WHERE A.NAME ='bisal/test_delete';
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
| TBL_SPACEID | TABLE_ID | TABLE_NAME | FILE_FORMAT | ROW_FORMAT | SPACE_TYPE | INDEX_ID | INDEX_NAME | PAGE_NO | INDEX_TYPE |
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
| 27 | 43 | bisal/test_delete | Barracuda | Dynamic | Single | 42 | PRIMARY | 3 | 3 |
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
1 row in set (0.00 sec)
此时，数据表的total_mb和data_mb是64M，free_mb是5M，
mysql> select table_schema, table_name, ENGINE, round(DATA_LENGTH/1024/1024+ INDEX_LENGTH/1024/1024) total_mb,TABLE_ROWS, round(DATA_LENGTH/1024/1024) data_mb, round(INDEX_LENGTH/1024/1024) index_mb, round(DATA_FREE/1024/1024) free_mb, round(DATA_FREE/DATA_LENGTH*100,2) free_ratio from information_schema.TABLES where TABLE_SCHEMA='bisal' and TABLE_NAME='test_delete';
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| table_schema | table_name | ENGINE | total_mb | TABLE_ROWS | data_mb | index_mb | free_mb | free_ratio |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| bisal | test_delete | InnoDB | 64 | 1096368 | 64 | 0 | 5 | 7.86 |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
1 row in set (0.00 sec)
再来看下数据文件的信息，插入110万数据，一共分配了4608个页，数据页是4021个，原来的根节点(page offset=3)升级为了存储目录项的页，page offset=4开始成为了叶子节点的数据页，page level=2，说明此时B树已经有3层了，
[mysql@bisal py_innodb_page_info-master]$ python py_innodb_page_info.py /mysql/3306/data/bisal/test_delete.ibd -v | less
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0002>
page offset 00000004, page type <B-tree Node>, page level <0000>
page offset 00000005, page type <B-tree Node>, page level <0000>
page offset 00000006, page type <B-tree Node>, page level <0000>
page offset 00000007, page type <B-tree Node>, page level <0000>
page offset 00000008, page type <B-tree Node>, page level <0000>
page offset 00000009, page type <B-tree Node>, page level <0000>
page offset 0000000a, page type <B-tree Node>, page level <0000>
page offset 0000000b, page type <B-tree Node>, page level <0000>
page offset 0000000c, page type <B-tree Node>, page level <0000>
page offset 0000000d, page type <B-tree Node>, page level <0000>
page offset 0000000e, page type <B-tree Node>, page level <0000>
page offset 0000000f, page type <B-tree Node>, page level <0000>
page offset 00000010, page type <B-tree Node>, page level <0000>
page offset 00000011, page type <B-tree Node>, page level <0000>
page offset 00000012, page type <B-tree Node>, page level <0000>
page offset 00000013, page type <B-tree Node>, page level <0000>
page offset 00000014, page type <B-tree Node>, page level <0000>
page offset 00000015, page type <B-tree Node>, page level <0000>
page offset 00000016, page type <B-tree Node>, page level <0000>
page offset 00000017, page type <B-tree Node>, page level <0000>
page offset 00000018, page type <B-tree Node>, page level <0000>
page offset 00000019, page type <B-tree Node>, page level <0000>
page offset 0000001a, page type <B-tree Node>, page level <0000>
page offset 0000001b, page type <B-tree Node>, page level <0000>
page offset 0000001c, page type <B-tree Node>, page level <0000>
page offset 0000001d, page type <B-tree Node>, page level <0000>
page offset 0000001e, page type <B-tree Node>, page level <0000>
page offset 0000001f, page type <B-tree Node>, page level <0000>
page offset 00000020, page type <B-tree Node>, page level <0000>
page offset 00000021, page type <B-tree Node>, page level <0000>
page offset 00000022, page type <B-tree Node>, page level <0000>
page offset 00000023, page type <B-tree Node>, page level <0000>
page offset 00000024, page type <B-tree Node>, page level <0001>
page offset 00000025, page type <B-tree Node>, page level <0001>
page offset 00000026, page type <B-tree Node>, page level <0001>
page offset 00000027, page type <B-tree Node>, page level <0001>
page offset 00000000, page type <Freshly Allocated Page>
...
page offset 00000000, page type <Freshly Allocated Page>
Total number of page: 4608:
Freshly Allocated Page: 585
Insert Buffer Bitmap: 1
File Space Header: 1
B-tree Node: 4021
File Segment inode: 1
现在执行删除的操作，delete删除110万数据，
mysql> delete from test_delete;
Query OK, 1100000 rows affected (3.18 sec)
select *操作执行时间，已经秒出了，从现象上看，和我们按照Oracle思维设想数据delete删除了，所谓“高水位"没降仍会影响数据检索的效率是恰恰相反的，
mysql> select count(*) from test_delete;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)mysql> select * from test_delete where name = 'X';
Empty set (0.00 sec)
此时，操作系统上的数据文件还是44M，这点和Oracle相同，delete操作不会主动回收操作系统文件的存储空间，
-rw-r-----. 1 mysql mysql 8.0K 18 17:46 test_delete.frm
-rw-r-----. 1 mysql mysql 44M 19 18:20 test_delete.ibd
TBL_SPACEID、TABLE_ID等信息均为改动，
mysql> SELECT A.SPACE AS TBL_SPACEID, A.TABLE_ID, A.NAME AS TABLE_NAME, FILE_FORMAT, ROW_FORMAT, SPACE_TYPE, B.INDEX_ID , B.NAME AS INDEX_NAME, PAGE_NO, B.TYPE AS INDEX_TYPE FROM INNODB_SYS_TABLES A LEFT JOIN INNODB_SYS_INDEXES B ON A.TABLE_ID =B.TABLE_ID WHERE A.NAME ='bisal/test_delete';
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
| TBL_SPACEID | TABLE_ID | TABLE_NAME | FILE_FORMAT | ROW_FORMAT | SPACE_TYPE | INDEX_ID | INDEX_NAME | PAGE_NO | INDEX_TYPE |
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
| 27 | 43 | bisal/test_delete | Barracuda | Dynamic | Single | 42 | PRIMARY | 3 | 3 |
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
1 row in set (0.01 sec)
数据表的容量，还是64M，
mysql> select table_schema, table_name, ENGINE, round(DATA_LENGTH/1024/1024+ INDEX_LENGTH/1024/1024) total_mb,TABLE_ROWS, round(DATA_LENGTH/1024/1024) data_mb, round(INDEX_LENGTH/1024/1024) index_mb, round(DATA_FREE/1024/1024) free_mb, round(DATA_FREE/DATA_LENGTH*100,2) free_ratio from information_schema.TABLES where TABLE_SCHEMA='bisal' and TABLE_NAME='test_delete';
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| table_schema | table_name | ENGINE | total_mb | TABLE_ROWS | data_mb | index_mb | free_mb | free_ratio |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| bisal | test_delete | InnoDB | 64 | 44857 | 64 | 0 | 26 | 40.89 |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
1 row in set (0.00 sec)
但是从数据文件，我们看到，虽然分配的页，还是4608，按照我的理解，此时虽然页存在，但是其中已经没有数据了，原来存储目录项的页(page offset=3)已经被删除，无需扫描，实际执行SQL的时候，读取这个B树，已经没什么代价了，这是和Oracle堆表受“高水位”影响最重要的区别，
[mysql@bisal py_innodb_page_info-master]$ python py_innodb_page_info.py /mysql/3306/data/bisal/test_delete.ibd -v | less
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000>
page offset 00000004, page type <B-tree Node>, page level <0000>
page offset 00000005, page type <B-tree Node>, page level <0000>
page offset 00000006, page type <B-tree Node>, page level <0000>
page offset 00000007, page type <B-tree Node>, page level <0000>
page offset 00000008, page type <B-tree Node>, page level <0000>
page offset 00000009, page type <B-tree Node>, page level <0000>
page offset 0000000a, page type <B-tree Node>, page level <0000>
page offset 0000000b, page type <B-tree Node>, page level <0000>
page offset 0000000c, page type <B-tree Node>, page level <0000>
page offset 0000000d, page type <B-tree Node>, page level <0000>
page offset 0000000e, page type <B-tree Node>, page level <0000>
page offset 0000000f, page type <B-tree Node>, page level <0000>
page offset 00000010, page type <B-tree Node>, page level <0000>
page offset 00000011, page type <B-tree Node>, page level <0000>
page offset 00000012, page type <B-tree Node>, page level <0000>
page offset 00000013, page type <B-tree Node>, page level <0000>
page offset 00000014, page type <B-tree Node>, page level <0000>
page offset 00000015, page type <B-tree Node>, page level <0000>
page offset 00000016, page type <B-tree Node>, page level <0000>
page offset 00000017, page type <B-tree Node>, page level <0000>
page offset 00000018, page type <B-tree Node>, page level <0000>
page offset 00000019, page type <B-tree Node>, page level <0000>
page offset 0000001a, page type <B-tree Node>, page level <0000>
page offset 0000001b, page type <B-tree Node>, page level <0000>
page offset 0000001c, page type <B-tree Node>, page level <0000>
page offset 0000001d, page type <B-tree Node>, page level <0000>
page offset 0000001e, page type <B-tree Node>, page level <0000>
page offset 0000001f, page type <B-tree Node>, page level <0000>
page offset 00000020, page type <B-tree Node>, page level <0000>
page offset 00000021, page type <B-tree Node>, page level <0000>
page offset 00000022, page type <B-tree Node>, page level <0000>
page offset 00000023, page type <B-tree Node>, page level <0000>
page offset 00000024, page type <B-tree Node>, page level <0001>
page offset 00000025, page type <B-tree Node>, page level <0001>
page offset 00000026, page type <B-tree Node>, page level <0001>
page offset 00000027, page type <B-tree Node>, page level <0001>
page offset 00000000, page type <Freshly Allocated Page>
...
page offset 00000000, page type <Freshly Allocated Page>
Total number of page: 4608:
Freshly Allocated Page: 585
Insert Buffer Bitmap: 1
File Space Header: 1
B-tree Node: 4021
File Segment inode: 1
Oracle也有索引组织表，即Index Organized Table，简称IOT，如果使用delete删除IOT的数据，他的现象是否和MySQL相同？
我们创建一张IOT，同样插入110万数据，
SQL> create table t_iot(ID varchar2 (10),NAME varchar2 (20),constraint pk_id primary key (ID)
) organization index;SQL> create index idx_iot_01 on t_iot(name);
执行一条SQL，用时110毫秒，
SQL> select * from test_delete where name='X';
no rows selectedElapsed: 00:00:00.11
删除所有数据，
SQL> delete from test_delete;
1100000 rows deleted.
Elapsed: 00:00:07.42
再次执行SQL，用时30毫秒，这个现象和MySQL是相同的，
SQL> select * from test_delete where name='x';
no rows selected
Elapsed: 00:00:00.03
虽然，执行时间和数据质量有关，未必非常准确，但是至少说明了，IOT类型的表，在使用delete删除，select执行的时间上，并不会受到“高水位”的影响。其实，从严格的意义讲，刚才这句话，以及将堆表和IOT进行比较，都是不准确的，因为对索引组织表来说，就没有堆表这种“全表扫描”的操作，他就不是个“表”，他就是个“索引"，扫的都是B树，以上例中IOT的执行计划为证，用的是索引快速全扫描，即使我指定/+* full(test_delete) */，我们看到提示"FULL hint is same as INDEX_FFS for IOT"，说明对索引组织表来说，全表扫描就等于索引库快速全扫描，这些都是索引组织表的数据存储结构决定的，
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 779 | 1028 (1)| 00:00:01 |
|* 1 | INDEX FAST FULL SCAN| PK_ID | 1 | 779 | 1028 (1)| 00:00:01 |
------------------------------------------------------------------------------
话再说回来，对这种索引组织表执行delete删除，虽然看着好像没什么影响，但实际上，如果有条件，还是需要做下重构的，原因就是表的数据删除了，但是文件未收缩，数据存储在文件系统上的，删除数据等这些操作，都会在页面上留下一些“空洞”，或者随机写入会导致页分裂(导致页面的利用空间更少)，另外对表进行增删改会引起对应的二级索引值的随机增删改，也会导致索引结构中的数据页面上留下一些“空洞”，虽然这些空洞有可能会被重复利用，但是还可能导致部分物理空间未被使用，也就是碎片，当检索数据的时候可能就会消耗更多的IO、CPU等资源。
MySQL回收空间的操作，可能有很多种，我刚学到了两种，
方案1，optimize table操作，会锁表，但从效果看，1200万数据，生产环境1秒多，还是能接受的，具体时间取决于数据质量和环境，建议通过测试，确定具体操作，
mysql> optimize table test_delete;
+-------------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-------------------+----------+----------+-------------------------------------------------------------------+
| bisal.test_delete | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| bisal.test_delete | optimize | status | OK |
+-------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)
此时，文件已经成96K了，
-rw-r-----. 1 mysql mysql 8.0K 19 18:22 test_delete.frm
-rw-r-----. 1 mysql mysql 96K 19 18:22 test_delete.ibd
方案2，alter table，这是一种online DDL操作，但是会消耗更多的空间等资源，相当于自动创建中间表进行切换，
mysql> alter table test_delete engine=Innodb;
Query OK, 0 rows affected (0.05 sec)
Records: 0 Duplicates: 0 Warnings: 0
方案1和2，都是相当于对表进行了重构，执行完成，TBL_SPACEID、TABLE_ID、INDEX_ID的值都改了，
mysql> SELECT A.SPACE AS TBL_SPACEID, A.TABLE_ID, A.NAME AS TABLE_NAME, FILE_FORMAT, ROW_FORMAT, SPACE_TYPE, B.INDEX_ID , B.NAME AS INDEX_NAME, PAGE_NO, B.TYPE AS INDEX_TYPE FROM INNODB_SYS_TABLES A LEFT JOIN INNODB_SYS_INDEXES B ON A.TABLE_ID =B.TABLE_ID WHERE A.NAME ='bisal/test_delete';
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
| TBL_SPACEID | TABLE_ID | TABLE_NAME | FILE_FORMAT | ROW_FORMAT | SPACE_TYPE | INDEX_ID | INDEX_NAME | PAGE_NO | INDEX_TYPE |
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
| 32 | 44 | bisal/test_delete | Barracuda | Dynamic | Single | 44 | PRIMARY | 3 | 3 |
+-------------+----------+-------------------+-------------+------------+------------+----------+------------+---------+------------+
1 row in set (0.00 sec)
确实空间都已经被回收了，
mysql> select table_schema, table_name, ENGINE, round(DATA_LENGTH/1024/1024+ INDEX_LENGTH/1024/1024) total_mb,TABLE_ROWS, round(DATA_LENGTH/1024/1024) data_mb, round(INDEX_LENGTH/1024/1024) index_mb, round(DATA_FREE/1024/1024) free_mb, round(DATA_FREE/DATA_LENGTH*100,2) free_ratio from information_schema.TABLES where TABLE_SCHEMA='bisal' and TABLE_NAME='test_delete';
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| table_schema | table_name | ENGINE | total_mb | TABLE_ROWS | data_mb | index_mb | free_mb | free_ratio |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
| bisal | test_delete | InnoDB | 0 | 0 | 0 | 0 | 0 | 0.00 |
+--------------+-------------+--------+----------+------------+---------+----------+---------+------------+
1 row in set (0.00 sec)
数据文件也都回到了初始状态，
[mysql@bisal py_innodb_page_info-master]$ python py_innodb_page_info.py /mysql/3306/data/bisal/test_delete.ibd -v
page offset 00000000, page type <File Space Header>
page offset 00000001, page type <Insert Buffer Bitmap>
page offset 00000002, page type <File Segment inode>
page offset 00000003, page type <B-tree Node>, page level <0000>
page offset 00000000, page type <Freshly Allocated Page>
page offset 00000000, page type <Freshly Allocated Page>
Total number of page: 6:
Freshly Allocated Page: 2
Insert Buffer Bitmap: 1
File Space Header: 1
B-tree Node: 1
File Segment inode: 1
其他方式，例如导入导出、truncate，都可以起到相同的效果。具体用什么方案，还是得结合实际的需求，例如存在不存在停机时间？需要追加增量的数据？
这个问题，看着好像不是很复杂，但是要细琢磨，确实能找到很多模糊的知识点，可能这个就是eygle曾经说的“由点及面”。我们碰到一个问题的时候，很可能就会引申出其他的问题，不知道，不清楚，模棱两可，不能自圆其说，就说明对这个问题没理解清楚，这需要我们能静下来，踏实地研究一下，虽然过程很艰难，还可能没得到任何答案，但是日积月累，方向上正确，就会让自己得到一些提升，共勉共勉了。
小白学习MySQL，
《小白学习MySQL - 数据库软件和初始化安装》
《小白学习MySQL - 闲聊聊》
小白学习MySQL - MySQL会不会受到“高水位”的影响？相关推荐
- 小白学习MySQL - 一次慢SQL的定位
同事提了个问题,某套测试环境MySQL执行语句出现hang. 作为小白,每次碰到问题,都是在积累经验.执行SQL出现hang,说明应该有会话处于等待状态,可以通过show processlist看下当 ...
- 小白学习MySQL - 不同版本创建用户的些许区别
MySQL创建用户有很多种方法,例如常规create user,再通过grant,授予权限,还可直接grant连带创建用户和授权一起做了.最近创建过程中,发现不同版本操作有些区别. MySQL 5.7 ...
- 小白学习MySQL - 聊聊数据备份的重要性
最近某套MySQL数据库服务器异常关机,导致MySQL不能正常拉起来,启动过程中,error日志中记录了如下的信息,可以看到,数据库因为异常关闭,此时会进行实例恢复的操作, [Note] InnoDB ...
- 小白学习MySQL - 增量统计SQL的需求
这篇文章在爱可生开源社区首发<技术分享 | MySQL中一个聚类增量统计 SQL 的需求>. 同事提了一个MySQL数据库中SQL增量统计的问题,我用测试数据模拟一下,测试表tt有三个字段 ...
- 小白学习MySQL - Generated Columns功能
碰巧看到MySQL有这种的语法"INTEGER GENERATED ALWAYS AS IDENTITY",一知半解,了解一下. 官方文档介绍了这种Generated Column ...
- 小白学习MySQL - varchar类型字段为什么经常定义成255？
很多时候我们看到一些表字符串类型的字段定义为varchar(255),开始以为varchar只能定义为255这个长度值,其实不然. 官方文档所说,varchar有效的最大长度取决于行的容量,以及用的字 ...
- 小白学习MySQL - InnoDB支持optimize table？
MySQL数据库中进行表空间整理,可以用的一种操作就是optimize table, OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL]TABLE tbl_name [, tb ...
- 小白学习MySQL - 数据库软件和初始化安装
作为个人学习环境来说,搭建一套VMWare的环境,算是性价比最高的一种选择,当然你可以购买一些公有云服务器(有些则是免费的,例如Oracle Cloud,可参考<Oracle Cloud云端账号 ...
- 以下用于数据存储领域的python第三方库是-Python3爬虫学习之MySQL数据库存储爬取的信息详解...
本文实例讲述了Python3爬虫学习之MySQL数据库存储爬取的信息.分享给大家供大家参考,具体如下: 数据库存储爬取的信息(MySQL) 爬取到的数据为了更好地进行分析利用,而之前将爬取得数据存放在 ...
- php django mysql配置文件_Mysql学习Django+mysql配置与简单操作数据库实例代码
<Mysql学习Django+mysql配置与简单操作数据库实例代码>要点: 本文介绍了Mysql学习Django+mysql配置与简单操作数据库实例代码,希望对您有用.如果有疑问,可以联 ...
最新文章
- python __builtins__ credits类 （15）
- 点对点信道互连以太网实验_以太网防雷器通讯参数测试（二）——防雷器对高速链路影响的参数...
- 机器学习中的数据预处理（sklearn preprocessing）
- 2017-9-15-Linux移植：WinSCP软件 SSH Server开启
- 将关闭窗口的按钮放在窗口右边
- 蚂蚁中间件团队Java面试题：Netty+Redis+Kafka+MongoDB+分布式
- Linux ls命令：查看目录下文件
- LRU算法数组实现超简单
- sysadmin默认密码_Sysadmin工具，Kconfig / kbuild的秘密，11个KDE应用程序，tcpdump，Laverna，Python等
- 鸿蒙适配倒计时,华为鸿蒙OS2.0手机系统定档 鸿蒙OS2.0上线倒计时
- 在一个windows服务下，安装多个mysql服务。
- 计算机文件系统小结,文件系统总结
- php中 被遗忘的函数
- 「 C++ MFC 」“设置线程运行多媒体定时器”教程
- GO的lua虚拟机 gopher-lua
- Dim 和 Redim
- 服务器Ubuntu 16.04 更新NVIDIA显卡驱动-命令行版本及报错完美解决
- 坚定文化新自信 提升文化软实力
- LaTeX 算法代码排版 --latex2e范例总结
- json.dumps、json.loads()、json.dump(）、json.load（）学习笔记