MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意
再可以实现一个初步的思路。
然后继续升华一些,借助rownum来实现,当然在MySQL中原生不支持这个特性,需要间接实现。
写一个完整的语句,如下:
通过这个案例,可以很明显发现是第1行的记录,然后做了count(*)的操作。 当然我们的目标是要掌握rowid和主键的一些关联关系,所以我们也复盘一下主键使用中的隐患问题。 问题2:rowid和主键有什么关联关系 在学习MySQL开发规范之索引规范的时候,强调过一个要点:每张表都建议有主键。我们在这里来简单分析一下为什么? 除了规范,从存储方式上来说,在InnoDB存储引擎中,表都是按照主键的顺序进行存放的,我们叫做聚簇索引表或者索引组织表(IOT),表中主键的参考依据如下: (1)显式的创建主键Primary key。 (2)判断表中是否有非空唯一索引,如果有,则为主键。 (3)如果都不符合上述条件,则会生成UUID的一个隐式主键(6字节大)。 从以上可以看到,MySQL对于主键有一套维护机制,而一些常见的索引也会产生相应的影响,比如唯一性索引、非唯一性索引、覆盖索引等都是辅助索引(secondary index,也叫二级索引),从存储的角度来说,二级索引列中默认包含主键列,如果主键太长,也会使得二级索引很占空间。 问题3:在主键的使用中存在哪些隐患 这就引出行业里非常普遍的主键性能问题,这不是一个单一的问题,需要MySQL方向持续改造的,将技术价值和业务价值结合起来。我看到很多业务中设置了自增列,但是大多数情况下,这种自增列却没有实际的业务含义,尽管是主键列保证了ID的唯一性,但是业务开发无法直接根据主键自增列来进行查询,于是他们需要寻找新的业务属性,添加一系列的唯一性索引,非唯一性索引等等,这样一来我们坚持的规范和业务使用的方式就存在了偏差。 (编辑:PHP编程网 - 黄冈站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |