关于sql中count写法的切磋
这里我们讨论用binlog来实现闪回的方案。我们在查询表中数据的数目时，有人喜好用count(*)，有人用count(1)，另有些伴侣会用count(主键)，但这几种用法那种会更优一些呢？上面在csdn下面看到的一篇文章，摘抄以下：关于COUNT的写法，大抵有以下几种：
COUNT(*)
COUNT(1)
COUNT(主键)
COUNT(列名)
我仍是写个小例子：
USETEMPDB
GO
IFOBJECT_ID(TB)ISNOTNULLDROPTABLETB
GO
CREATETABLETB(COL1INT,COL2INT,COL3INT,COL4INT)
GO
CREATECLUSTEREDINDEXINX_TB_COL1_COL2ONTB(COL1,COL2)
GO
CREATEINDEXINX_TB_COL3ONTB(COL3)
GO
INSERTINTOTB
SELECTT1.number,T2.number,CASEWHENT1.number%3=0THENNULLELSET1.numberEND,T1.NUMBER+T2.number
FROMMASTER..spt_valuesT1
INNERJOINMASTER..spt_valuesT2ONT1.number=T2.number-1
GO
SELECTCOUNT(*)
FROMTB
SELECTCOUNT(1)
FROMTB
SELECTCOUNT(COL1)
FROMTB
SELECTCOUNT(COL2)
FROMTB
SELECTCOUNT(COL3)
FROMTB
SELECTCOUNT(COL4)
FROMTB
SELECTCOUNT(DISTINCTCOL3)
FROMTB
SELECTCOUNT(1),
COUNT(COL3),
COUNT(DISTINCTCOL3),
COUNT(COL4),
COUNT(DISTINCTCOL4)
FROMTB
本人逐一运转SELECT看实行企图，你会发明前五个的实行企图看起来是一样的，都是走INX_TB_COL3，这是由于体系判别COL3的索引巨细小于COL1+COL2的会萃索引，并且COL3中包括了前五个语句所必要的一切列。
但看到第一步的INDEX_SCAN中，会发明COUNT(*)和COUNT(1)是没有输入工具的，即假输入，只输入前往行数，不输入详细的列。而COUNT(COL1),COUNT(COL2),COUNT(COL3)都有一个OutPutLIST，分离是这三列。这是由于体系要算这三列中有几非NULL的值，而COUNT(*)和COUNT(1)都是有一行算一行，不论是不是NULL。
COUNT(COL4)走的是INX_TB_COL1_COL2，也就是会萃索引扫描了，由于COL3中只包括键列COL1、COL2和值列COL3，以是COUNT(COL4)没法走COL3，只能走会萃索引扫描，也就是全表扫描。
前面的COUNT(DISTINCTCOL3)是为了让你们对照企图的，所谓DISTINCT，就是在输入了COL3再GROUPBY一下再盘算行数。
最初一句是演示COUNT用法，无别的意义。
结论：
COUNT(1)和COUNT(*)是一样的,你能够在内里写任何常量，如COUNT(CSDNDSB),不会输入一列常量，不会往体系内外找一切列名。
COUNT(1)和COUNT(列名)意义分歧，不克不及放在一同对照。独一可对照的情形是列名是单主键表的主键列，即会萃非空单键值索引，这类情形下除非想要强迫走会萃索引扫描，不然COUNT(1)优于COUNT(列名)，由于前者同意企图选择最估索引，并且没有列输入。限制,如果WHERE子句的查询条件里有不等号（WHEREcoloum!=），MySQL将无法使用索引。类似地，如果WHERE子句的查询条件里使用了函数（WHEREDAY（column）=），MySQL也将无法使用索引。 如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。 其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！ 至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。 不好!如果出了错;不好调试;不好处理!其实web开发将代码分为3层:web层;业务逻辑层和数据访问层;一般对数据库的操作都在数据访问层来做;这样便于调试和维护!而且将来如果是换了数据库的话;你只需要改数据层的代码;其他层的基本可以不变!要是你在jsp中直接调用sql数据库;那么如果换了数据库呢?岂不都要改?如果报了异常呢?怎么做异常处理? 连做梦都在想页面结构是怎么样的，绝非虚言 现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层. 语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！
页:
[1]