CNDEV
CNDEV.ORG
当前在线
论坛
CBD
程序员情感CBD
程序员见面交流会
CBD开发区
Java/J2ME
.NET/C#
数据库
Delphi/BCB
Visual C
其它
修真养身
中国象棋
纪念日
谈钱太俗，还是投机吧
听音乐
iCosta
资源共享
一隅
好文共赏
看电影看美剧
待定
狗屎
雪域召唤
工作流
专业显摆区
语录
情感
批评与自我批评
爱情故事
发牢骚
看三点区
游戏
CNDEV-CS/WOW
浩宇长空
生活
家有XPH
我爱学英语
美食天地ORG
半调子体育迷
观澳园友邻
搞笑奇文
拍照片
我读书我存在
论坛系统
超级垃圾站
系统建议及BUG
系统测试
中国开发网
: 论坛:
程序员情感CBD
: 贴子 394317
wynnhjg
：
索引真神奇,偶建了一个.
[阅读: 681] 2006-09-08 07:23:53
从6秒直接XX到0.4秒.
相关信息:
索引真神奇,偶建了一个.
(13字)
(
wynnhjg
[680]
2006-09-08 15:23
)
没这么简单，用起来要注意的地方很多的
(空) (
steel1
[478]
2006-09-08 15:24
)
还有些什么地方?
(84字)
(
wynnhjg
[488]
2006-09-08 15:30
)
没有分页么...
(空) (
dead_lee
[427]
2006-09-08 15:35
)
这个当然有了.
(空) (
wynnhjg
[398]
2006-09-08 15:46
)
那70w算什么啊
(空) (
dead_lee
[399]
2006-09-08 15:59
)
一个月70W条数据算什么
(10字)
(
好望角
[490]
2006-09-08 16:43
)
这个表是以读为主还是写为主？TPS是多少？
(空) (
Miracle
[417]
2006-09-08 15:34
)
主要是以插入为主.
(6字)
(
wynnhjg
[493]
2006-09-08 15:47
)
那还建
(空) (
zhenghj
[420]
2006-09-08 15:48
)
可是查询也还是有的呀.
(32字)
(
wynnhjg
[466]
2006-09-08 15:50
)
不是不可以建，而是要注意策略。
(空) (
Miracle
[410]
2006-09-08 15:59
)
如果insert/update较多，query压力又比较大的话，建议不要把query直接施加在live table上面，而是定时转移数据，在archive table上查询
(空) (
Miracle
[532]
2006-09-08 16:00
)
这样可以保持live data尺寸接近最小，避免因锁定引起故障，又可以在archive table上面施加合理的索引，提高查询执行效能
(空) (
Miracle
[481]
2006-09-08 16:00
)
副作用是数据不同步了
(空) (
JoJo
[431]
2006-09-08 16:02
)
多数企业，对于数据的实时同步性要求没有那么高。15分钟到30分钟的不同步，大部分非关键应用都可以接受
(空) (
Miracle
[454]
2006-09-08 16:03
)
其实如果数据总是增加而不经常修改删除的话，预填索引空间即可
(空) (
JoJo
[485]
2006-09-08 16:04
)
这个好
(空) (
dead_lee
[398]
2006-09-08 16:06
)
如果确实要求同步，也有很多办法，常见的低成本办法如增加物理驱动器，然后对表进行合理的数据分区（如按时间分区）并把数据文件合理的分散到不同物理驱动器上来获取最大IO效能。
(空) (
Miracle
[478]
2006-09-08 16:07
)
你这种中后期移动风险性太大
(67字)
(
python
[459]
2006-09-08 16:21
)
瞧，这才是你的典型帖子风格。
(空) (
Miracle
[453]
2006-09-08 16:27
)
这就是认真与不认真的风格.
(空) (
python
[418]
2006-09-08 16:29
)
让插入的多等一秒,好过查询的人多等10秒..
(空) (
dead_lee
[413]
2006-09-08 16:00
)
非也，如果每时每刻都有几十个insert/updates，这样设计系统就是死路一条了。应该都不耽误
(空) (
Miracle
[399]
2006-09-08 16:02
)
股票交易
(空) (
fogbound
[436]
2006-09-08 16:17
)
别一棒子打死.各个系统(用户)对待数据的相应时间是不同的.
(15字)
(
python
[461]
2006-09-08 16:26
)
秒级的插入等待，女人可以，计算机方面就恐怖了。别强调其他条件
(空) (
Miracle
[472]
2006-09-08 16:28
)
靠.太BT了.
(空) (
wynnhjg
[362]
2006-09-08 16:34
)
非也非也。查询、报表的时候用户多等一会是可以接受的，但如果速度影响到业务操作，则是不可忍受的。
(空) (
疯子张
[430]
2006-09-08 16:36
)
这也叫神奇
(5字)
(
老玉米
[429]
2006-09-08 15:45
)
一个表上建立索引即有好处也有坏处
(284字)
(
python
[2703]
2006-09-08 16:11
)
DB高手.
(空) (
wynnhjg
[351]
2006-09-08 16:13
)
怎么这么井井有条，错别字也没几个，不是你平时大篇打字的风格阿。
(空) (
Miracle
[489]
2006-09-08 16:16
)
靠.光指望我发错别字.发时扫描了几遍错别字.
(空) (
python
[366]
2006-09-08 16:23
)
不错，有进步！
(空) (
Miracle
[408]
2006-09-08 16:26
)
说说联合index,联合index里有那个字段的,可是偶又单独建了一个index.
(8字)
(
wynnhjg
[559]
2006-09-08 16:19
)
clustered index使用上更要注意，如果你的查询条件不实用clustered index前面的字段，那基本上没有什么用处
(空) (
Miracle
[484]
2006-09-08 16:20
)
而且clustered index迫使表数据/索引数据进行排序，导致在indexed columns上面进行不规则insert/update效能低于普通index
(空) (
Miracle
[564]
2006-09-08 16:22
)
如果你的查询条件不使用clustered index前面的字段，那基本上没有什么用
(15字)
(
wynnhjg
[487]
2006-09-08 16:23
)
建了clustered insert就更慢了
(空) (
zhenghj
[429]
2006-09-08 16:28
)
不见得，看怎么建了
(空) (
JoJo
[383]
2006-09-08 16:29
)
Insert好点,做delete/update就很难受了
(空) (
zhenghj
[407]
2006-09-08 16:35
)
看来你对clustered index概念一无所知。。。
(空) (
JoJo
[432]
2006-09-08 16:28
)
靠，以为你回的是我的帖子，把我搞一头雾水。原来XPH复制了我的帖子然后再里面提问，晕
(空) (
Miracle
[449]
2006-09-08 16:29
)
哈哈。。。
(空) (
JoJo
[402]
2006-09-08 16:30
)
这说的不对?
(111字)
(
wynnhjg
[479]
2006-09-08 16:38
)
主键不一定要做clustered index,我觉得最好不要做clustered index!
(空) (
zhenghj
[551]
2006-09-08 16:44
)
人家没说主键一定要做clustered index啊
(空) (
Miracle
[406]
2006-09-08 16:46
)
不是按上面帖子的意思,说下来的吗
(空) (
zhenghj
[395]
2006-09-08 16:50
)
你回的那个帖子里没说
(空) (
Miracle
[381]
2006-09-08 16:51
)
对，但没说clustered index
(空) (
JoJo
[513]
2006-09-08 16:45
)
where就是缩小查询条件，前面的尽量写索引列的条件。这个也很又讲究的吧。
(空) (
龙之吻
[444]
2006-09-08 16:46
)
实用->使用
(空) (
Miracle
[364]
2006-09-08 16:22
)
不见得,这得看索引的群集比率,集群因子的集群级别。
(空) (
python
[549]
2006-09-08 16:42
)
倒，你还真能抠。
(9字)
(
Miracle
[394]
2006-09-08 16:43
)
说的不错。所以，在进行批量插入、更新的时候，通常的办法是删除索引，完了之后再重建。
(空) (
茶壶
[494]
2006-09-08 23:44
)
欢迎光临本社区，您还没有登录，不能发贴子。请在
这里登录
| -ICP -IDC -ISP |