主键、索引的困惑

Water Lee 2019-08-25 09:20:45

平时建表都会习惯性创建主键，但总会忘记索引。其实是对索引不确定。有几个小白问题请教，请各位指点
场景:开发超市收银系统，创建零售信息表，很自然会创建一个流水号作为主键以便于和其它表联接（例如零售明细表）。但是实际运用时，作为主键的流水号很少会在where中出现，反而是创建时间。例如查销量，统计某个商品销售情况，生成销售报表等。这时觉得如果在创建时间上创建一个过索引会不会要好一些，但查到的资料都提醒说，创建索引后查询会加快，但 Insert 会更加费时。
这样我就矛盾了，对于超市，收银时的 Insert 是很频繁的，但后台管理时，各种报表对销量的查询也是很频繁的。
各位帮忙分析一下要不要创建这个过引。

大概表结构
零售信息表
字段：零售ID(PK)，创建时间，.....（其它信息）

零售明细表
字段：零售ID,商品条码，销售数量，......（其它信息）

...全文

513 27 打赏收藏转发到动态举报

写回复

用AI写文章

27 条回复

切换为时间正序

请发表友善的回复…

发表回复

Water Lee 2019-10-14

打赏
举报

没有设置太多的分，只能尽可能给了，感谢各位!

angel6709 2019-09-16

打赏
举报

引用 4 楼秋的红果实的回复:

对于超市，后台查询因该不是很频繁你可以在查询时建立索引，查完删除，此过程即使和前台的销售重叠，也是短暂的至于主键和索引，前者强调唯一性，他们都是键

这种方法不可取。

eduiH 2019-09-14

打赏
举报

不是说单号是唯一主键吗，会不会单号和时间就有关系😂

好奇都是要学的 2019-09-03

打赏
举报

如果就一个索引在insert的时候是没有什么影响的。但是20万数据，我觉得没有索引就一个主键查询也没啥问题。查报表是集合通过日期索引。查单个商品是通过主键。在加上各种关联表。所以日期加个索引插入不会影响什么

riven2011 2019-09-02

打赏
举报

直接按创建时间分区，不要索引

脆皮大雪糕 2019-08-30

打赏
举报

一张表，建立两三个索引没有太大问题，但别多，多了的确很影响。一个索引到底建不建其实还要看业务数据场景。看题主的意思，数据会定期进行转存，也就是说终端数据其实顶多也就几天的。那么这时候对日期的索引意义就不大了，即使门店一天有三五千条数据，本地两三万条数据，只有四五个日期，索引效率并不高。如果每天转存，那么终端数据库里只有当天数据，那么这个日期索引就毫无意义。终端本地是否存储历史数据，也要看终端的业务场景频度，比如营业网点仅仅是每天打烊后汇总一下当天总数，月底再汇总一下，甚至月报季报半年报年报都由总部一口气做了，那么终端完全可以仅保留当日数据，月底的数据上云端查去。云端这个索引就必须了。如果门店比较多，那么除了日期索引，建议还要用分区表来存储，比如一个季度一个区或一年一个区之类的。还有就是费好大劲产生的统计结果，就干脆做个表存储下来，比如月统计季度统计啥的，回头你要做过去五年十年的统计分析的时候就轻松了。

SinGooCMS 2019-08-30

打赏
举报

where 后面的查询频繁的字段建立索引。

xiaoxiangqing 2019-08-30

打赏
举报

主键一定是索引，但索引不一定是主键

Water Lee 2019-08-29

打赏
举报

感谢各位指点，我现在的考虑是，将所有零售数据都放到云端服务器，然后在云端该建索引的就建索引。而客户端不管网络是否连通，都不再直接将数据写到云服务器，而是先存在本地，由另一个后台程序转传（因为后台转传，不用要求实时性很高），这样，终端 INSERT 就不会受索引影响，而查询时直接查云服务器的数据又能使用索引。不知道这样是否合理？

就等你一会儿 2019-08-29

打赏
举报

复制粘贴加积分，不好意思。对于超市，后台查询因该不是很频繁你可以在查询时建立索引，查完删除，此过程即使和前台的销售重叠，也是短暂的至于主键和索引，前者强调唯一性，他们都是键

angel6709 2019-08-29

打赏
举报

引用楼主 Water Lee 的回复:

平时建表都会习惯性创建主键，但总会忘记索引。其实是对索引不确定。有几个小白问题请教，请各位指点场景:开发超市收银系统，创建零售信息表，很自然会创建一个流水号作为主键以便于和其它表联接（例如零售明细表）。但是实际运用时，作为主键的流水号很少会在where中出现，反而是创建时间。例如查销量，统计某个商品销售情况，生成销售报表等。这时觉得如果在创建时间上创建一个过索引会不会要好一些，但查到的资料都提醒说，创建索引后查询会加快，但 Insert 会更加费时。这样我就矛盾了，对于超市，收银时的 Insert 是很频繁的，但后台管理时，各种报表对销量的查询也是很频繁的。各位帮忙分析一下要不要创建这个过引。大概表结构零售信息表字段：零售ID(PK)，创建时间，.....（其它信息）零售明细表字段：零售ID,商品条码，销售数量，......（其它信息）

你可以不建立索引。查询的报表可以后台生成。（转存）

Dzj731138 2019-08-29

打赏
举报

索引适当就好，太多了也不好

XBodhi. 2019-08-29

打赏
举报

首先主键就是索引，而且是聚集索引，一个表只能有1个聚集索引，但是可以有复合主键，其他的就是非聚合索引。通常都是查询比较高效的回简历这个，当然也有人用 NOSQL 的时候就没有意义了。因为 NOSQL 本来性能就很差。

爱读源码的大都督 2019-08-29

打赏
举报

肯定要对时间字段建立索引，至于对插入的影响不会特别大，第一，主键是不是自增的，如果是，影响很小，第二，时间本身也是自增的，所以影响也不大。我这么解释，依据的原理就是索引是有序的，只要你在插入的时候也是保证有序的就行。

hztltgg 2019-08-29

打赏
举报

引用 14 楼 Water Lee 的回复:

感谢各位指点，我现在的考虑是，将所有零售数据都放到云端服务器，然后在云端该建索引的就建索引。而客户端不管网络是否连通，都不再直接将数据写到云服务器，而是先存在本地，由另一个后台程序转传（因为后台转传，不用要求实时性很高），这样，终端 INSERT 就不会受索引影响，而查询时直接查云服务器的数据又能使用索引。不知道这样是否合理？

大型超市是极可能晚上进行同步数据的设计，还有各种etl抽取数据出报表，数据处理本来就有OLTP、OLAP之分。不过你这还在csdn上问，应该数据不会多，别想了，加个索引慢不到哪儿去的。