|
再可以实现一个初步的思路。
- 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_resultr ,(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），表中主键的参考依据如下：
（1）显式的创建主键Primary key。
（2）判断表中是否有非空唯一索引，如果有，则为主键。
（3）如果都不符合上述条件，则会生成UUID的一个隐式主键（6字节大）。
从以上可以看到，MySQL对于主键有一套维护机制，而一些常见的索引也会产生相应的影响，比如唯一性索引、非唯一性索引、覆盖索引等都是辅助索引（secondary index，也叫二级索引），从存储的角度来说，二级索引列中默认包含主键列，如果主键太长，也会使得二级索引很占空间。
问题3：在主键的使用中存在哪些隐患
这就引出行业里非常普遍的主键性能问题，这不是一个单一的问题，需要MySQL方向持续改造的，将技术价值和业务价值结合起来。我看到很多业务中设置了自增列，但是大多数情况下，这种自增列却没有实际的业务含义，尽管是主键列保证了ID的唯一性，但是业务开发无法直接根据主键自增列来进行查询，于是他们需要寻找新的业务属性，添加一系列的唯一性索引，非唯一性索引等等，这样一来我们坚持的规范和业务使用的方式就存在了偏差。 （编辑：衡阳站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
