MySQL中的主键和rowid,看似简朴，着实有一些行使陷阱必要留意

我们不妨通过一个案例来举办声名。

记得有一天统计备份数据的时辰，写了一条SQL，当看到执行功效时才发明SQL语句没有写完备，在完成统计事变之后，我筹备说明下这条SQL语句。

mysql> select backup_date ,count(*) piece_no from redis_backup_result;  
+-------------+----------+  
| backup_date | piece_no |  
+-------------+----------+  
| 2018-08-14 | 40906 |  
+-------------+----------+  
1 row in set (0.03 sec) 

按照营业特点，一天之内必定没有这么多的记录，明明差池，到底是那边出了题目呢。

本身细心看了下SQL，发明是没有加group by，我们随机查出10条数据。

mysql> select backup_date from redis_backup_result limit 10;  
+-------------+  
| backup_date |  
+-------------+  
| 2018-08-14 |  
| 2018-08-14 |  
| 2018-08-14 |  
| 2018-08-15 |  
| 2018-08-15 |  
| 2018-08-15 |  
| 2018-08-15 |  
| 2018-08-15 |  
| 2018-08-15 |  
| 2018-08-15 |  
+-------------+  
10 rows in set (0.00 sec) 

在早期的版本中数据库参数sql_mode默以为空，不会校验这个部门，从语法角度来说，是应承的；可是到了高版本，好比5.7版本之后是不支持的，以是办理方案很简朴，在添加group by之后，功效就切合预期了。

mysql> select backup_date ,count(*) piece_no from redis_backup_result group by backup_date;  
+-------------+----------+  
| backup_date | piece_no |  
+-------------+----------+  
| 2018-08-14 | 3 |  
| 2018-08-15 | 121 |  
| 2018-08-16 | 184 |  
| 2018-08-17 | 3284 |  
| 2018-08-18 | 7272 |  
| 2018-08-19 | 7272 |  
| 2018-08-20 | 7272 |  
| 2018-08-21 | 7272 |  
| 2018-08-22 | 8226 |  
+-------------+----------+  
9 rows in set (0.06 sec) 

可是较量好奇这个理会的逻辑，看起来是SQL理会了第一行，然后输出了count(*)的操纵，显然这是从执行打算中无法获得的信息。

我们换个思绪，可以看到这个表有4万多条的记录。

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

为了验证，我们可以行使_rowid的方法来做起源的验证。

InnoDB表中在没有默认主键的环境下会天生一个6字节空间的自动增添主键，可以用select _rowid from table来查询，如下：

mysql> select _rowid from redis_backup_result limit 5;  
+--------+  
| _rowid |  
+--------+  
| 117 |  
| 118 |  
| 119 |  
| 120 |  
| 121 |  
+--------+  
5 rows in set (0.00 sec) 

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!