如题：某字段上有索引，但该字段又会经常修改，但有索引修改肯定会受速度影响。那么，怎么解决这种情况，或者取舍？
大家踊跃发言，下周一结贴。
------解决思路----------------------
是指记录的修改时间吧. 会不会索引升序会好点
------解决思路----------------------
有资源的话做读写分离，就是另外建立一个读的表，上面有对应的索引。 （推荐）
如果没有过多资源，就需要找平衡点，看多少索引是可以接受的写入速度。这个需要根据实际使用状况调整。
读写，一直都是一个问题，即便是使用了内存数据库，不存在锁的情况下，排队也是问题。 分布式的去IOE可以一定程度上解决这类问题。 但也相应的会引入别的问题。
lz 参考。
------解决思路----------------------
要看这个“经常修改”的频率有多高。
索引修改本身是内存操作，速度很快的，问题是更新加锁会让其他会话产生等待，这才影响性能。
一方面是更新的频率和更新事务的时长，另一方面是是否在索引上有长时间的查询操作，两者共存才是问题。
------解决思路----------------------
增数据没问题，主要看是否顺序增加，改的话要看逻辑，一般影响较大。如果频率和影响范围都很大，那不建索引对维护开销来说更好，从设计上来说，经常变的值一般是用来“显示”而不是“筛选”
------解决思路----------------------
只要不是聚集索引，影响要小很多，所以一个表通常不要建过多索引，最好非聚集索引控制在5个以内。
要建一个维护索引整理和重建的JOB每日闲时自动运行一次
------解决思路----------------------
+1
------解决思路----------------------
这种情况经常出现，毕竟读是第一位的，数据毕竟要从硬盘上读到内存中，写，只要写入log 文件就算完成操作,可以参考以下设置：
1： 把 fill factor 设为70% or 80%, 可以避免很多的page split, 这个是很消耗资源的
2：为了保证read/write 更有效率， 把相关索引的统计信息即使更新，不太赞同高频度的rebuild/reorganize index.
3: 如果 deadlock/block 频度较高， 可以考虑禁用table lock escalation
4:可以更改下表的结构， 把整个表partition 为 6 个分区， 使逻辑上连续的行物理上分散到不同的分区。也可以减缓latch 的竞争如：
id int primary key
1 分区 2 分区 3分区 4 分区 5 分区 6 分区
1 2 3 4 5 6
7 8 9 10 11 12
13 14 15 16 17 18
.......
------解决思路----------------------
先学习了
只要不是聚集索引，影响要小很多，所以一个表通常不要建过多索引，最好非聚集索引控制在5个以内。
要建一个维护索引整理和重建的JOB每日闲时自动运行一次
这个不错
维护索引整理 和重建的 方法 想学习下