数据库教程:MySQL中主键与rowid的使用陷阱总结分享

前言

大家在MySQL中我们可能听到过rowid的概念，但是却很难去测试实践，不可避免会有一些疑惑，比如：

如何感受到rowid的存在； rowid和主键有什么关联关系； 在主键的使用中存在哪些隐患； 如何来理解rowid的潜在瓶颈并调试验证。

本文要和大家一起讨论这几个问题，测试的环境基于MySQL 5.7.19版本。

问题1、如何感受到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)

再可以实现一个初步的思路。

mysql> select _rowid,count(*)from redis_backup_result; +--------+----------+ | _rowid | count(*) | +--------+----------+ | 117 | 41036 | +--------+----------+ 1 row in set (0.03 sec)

然后继续升华一些，借助rownum来实现，当然在MySQL中原生不支持这个特性，需要间接实现。

mysql> SELECT @rowno:=@rowno+1 as rowno,r._rowid from redis_backup_result r ,(select @rowno:=0) t limit 20; +-------+--------+ | rowno | _rowid | +-------+--------+ | 1 | 117 | | 2 | 118 | | 3 | 119 | | 4 | 120 | | 5 | 121 | | 6 | 122 | | 7 | 123 | | 8 | 124 | | 9 | 125 | | 10 | 126 | | 11 | 127 | | 12 | 128 | | 13 | 129 | | 14 | 130 | | 15 | 131 | | 16 | 132 | | 17 | 133 | | 18 | 134 | | 19 | 135 | | 20 | 136 | +-------+--------+ 20 rows in set (0.00 sec)

写一个完整的语句，如下：

mysql> SELECT @rowno:=@rowno+1 as rowno,r._rowid ,backup_date,count(*) from redis_backup_result r ,(select @rowno:=0) t ; +-------+--------+-------------+----------+ | rowno | _rowid | backup_date | count(*) | +-------+--------+-------------+----------+ | 1 | 117 | 2018-08-14 | 41061 | +-------+--------+-------------+----------+ 1 row in set (0.02 sec)

通过这个案例，可以很明显发现是第1行的记录，然后做了count(*)的操作。

当然我们的目标是要掌握rowid和主键的一些关联关系，所以我们也复盘一下主键使用中的隐患问题。

问题2、rowid和主键有什么关联关系

在学习MySQL开发规范之索引规范的时候，强调过一个要点：每张表都建议有主键。我们在这里来简单分析一下为什么？

除了规范，从存储方式上来说，在InnoDB存储引擎中，表都是按照主键的顺序进行存放的，我们叫做聚簇索引表或者索引组织表（IOT），表中主键的参考依据如下：

显式的创建主键Primary key。 判断表中是否有非空唯一索引，如果有，则为主键。 如果都不符合上述条件，则会生成6个字节的bigint unsigned值。

从上述就是数据库技术:MySQL中主键与rowid的使用陷阱总结分享的全部内容，如果对大家有所用处且需要了解更多关于mysql数据库学习教程，希望大家多多关注—计算机技术网(www.ctvol.com)!