RMB2000求数据库优化

WY24420

就是在A表中每读一条记录就在B表中插入一条读取记录，读取A表记录时先要查询B表中是否存在读取过的记录
读取记录如果不存在就插入，如果存在就更新B表中记录的A表的读取记录的次数是吧？
根据你的描述，服务器硬件足够用了，我觉得锁是造成你这个性能问题的主要原因
首先A表和B表的查询在索引上做好优化，这是最基本的，除了优化索引，可以考虑从方案上做出改变

1，可以考虑对B表的插入或者更新采用异步的方式，保证客户端查询时优先返回查询结果，异步记录对A表的查询信息，需要在应用程序段做修改
2，如果不想在应用程序段做修改，可以考虑对B表分表，因为在往B表中Insert数据或者Update B表的记录时，是一个排他锁，将对并发有较大的影响，可以按照A表数据的类别，将读取记录记录到不同的表中，相当于把B表拆分成多个表，如果想统计这些表的信息，就简单了，合并成一个视图就行了

目前就想到这两点，不过我估计早就有高人搞定你这个需求了，哈哈

WY24420

1. drop table A
2. create table A
3. (
4.         col1 varchar(50),
5.         col2 varchar(50),
6.         col3 varchar(50)
7. )
9. insert into A values (NEWID(),NEWID(),NEWID())
10. go 50000
12. create clustered index index_1 on A (col1)
14. create table B
15. (
16.         col1 varchar(50),
17.         readcount int
18. )
19. create clustered index index_1 on B (col1)
21. select * from A
23. select * from B
26. select * from A where  A.col1='7C4C852D-9065-47A0-8939-85013BBD3873'
27. MERGE B  
28. USING (select col1 from A where A.col1='7C4C852D-9065-47A0-8939-85013BBD3873') AS T
29. ON B.col1=T.col1   
30. WHEN MATCHED THEN UPDATE SET B.readcount=B.readcount+1 --如果记录匹配，就更新目标表的匹配行
31. WHEN NOT MATCHED THEN INSERT(col1,readcount) VALUES(T.col1,1); --如果记录不匹配，就插入一条数据

复制代码

模仿100个线程，每个线程读取100次，好像也没那么慢

WY24420

突然想到，如果是高并发的环境，要防止热点页的问题，如果A表的主键列是自增的，对A表的访问又集中在某个特定的范围，
如果B表中存储的是A表的主键列上件聚集索引
就想办法尽可能把A的主键列在B表中分散存储，加一个GUID做聚集索引，
避免多个会话去修改的数据在一个页面上，造成另外的阀锁等待
我这个测试是想当然的，很多东西体现不出来，都是要根据具体情况做优化的

如果有人帮楼主搞定了，方便的话分享一下经验，多跟大神们学习学习

luckyrandom

简单的N个测试套路，不能涵盖现实中各种各样不同情况的场景
如果读下孙子兵法就是军事专家，太多玩军事的都该退出江湖
万物归宗：实事求是

eddyabc

各位都把问题复杂化了,问题出在NewId()函数，这个要全表扫描，并发情况下效率较低

WY24420

luckyrandom 发表于 2015-7-22 12:15
简单的N个测试套路，不能涵盖现实中各种各样不同情况的场景
如果读下孙子兵法就是军事专家，太多玩军事的都 ...

其实也没那么玄乎，测试的话要想到各种各样的情况，我反倒是觉得比现实情况更加复杂才有说服力
现实情况下，造成性能问题极有可能是常见原因之一或者之二或者之三，绝对不可能是十个八个原因一起造成的，这样把具体的问题抛出来就更容易下手

说个经历吧
以前面试的时候，经常由面试官问，有没有千万级表的处理经验，他们觉得千万级的表就是大表，
如果一个人认为千万级的表就是大表的话，他就根本没怎么接触过稍微大一点点的数据库，
也许N多年来也就是玩几万几十万数据的微型数据库
因为真正接触了才发现，N个千万级表的数据库，sql只要写的不是太烂，有基本的优化常识，
根本不会发生什么性能问题，不像传说中的那么玄乎

luckyrandom

技术是死的，一就是一，二就是二，恰恰不是玄乎
倒是太多场景下很多人忽略了问题细节、DB特点而已
或者说没用正确的招式解决特定的问题
对于多数情况，满足用户需求就是好方案，不一定需要达到最优、最好、最强

owen_zeng

eddyabc 发表于 2015-7-22 12:27
各位都把问题复杂化了,问题出在NewId()函数，这个要全表扫描，并发情况下效率较低

你说到了问题的关键之处，但是怎么解决呢

eddyabc

呵呵,付款贴代码

WY24420

luckyrandom 发表于 2015-7-22 15:12
技术是死的，一就是一，二就是二，恰恰不是玄乎
倒是太多场景下很多人忽略了问题细节、DB特点而已
或者说 ...

估计楼主的问题被你搞定了，可否分享一下经验