1. 如题，假设有一张表A，存放了“北京”、“上海”、“苏州”、“南京”等city的信息，表中的数据量可能达到上万条，那么是否有必要将表A根据city拆分，每一个city建立一张表？
2. 我经常用到的操作有2个：第一，根据城市名查询记录“select [字段名] from A where city = ''城市名”；第二，根据城市名插入记录。如果A的记录条数会影响查询效率和插入效率，那么当记录条数达到多少量级的时候会使得效率较低？
------解决方案--------------------
1.拆分了以后在CITY字段上加索引 查询效率很高的。
2.这个就要具体情况具体分析了 你可以通过查看执行计划去看看这些情况。
------解决方案--------------------
选择需要分区的表：
需要注意的是，没有任何规定和指标表明多大的表需要做分区，或者说，不能说非常大的表能通过分区带来效益。比如本人管理的一个系统中，有一个静态表，类似于字典表，有4000多万数据，导出成txt文件有10G。但是上面的索引策略足够支持应用系统的高效查询，这个表目前为止不需要做分区，分区了也不见得会带来什么好处，所以不是“大表”就要做分区。
规范一点的说法：不需要经常访问、不需要过多索引维护、静态的或者能通过使用多个文件组并存放在不同地方从而获取备份、联机还原或者部分还原的表，都不需要进行分区。
当一个表的维护开销明显超过预期，或者因为体积原因影响使用时，可以作为表分区的考虑对象。其中一些参考值为：
? 表上的索引维护操作时间和资源开销过大，但是可以通过分区，使其仅发生在部分分区而不是整个表上。
? 表上的数据周期性“过时”需要清理，而删除操作非常慢，或者阻塞了其他用户查询表。
? 数据需要周期性加载到表中，并且加载过程非常慢，但是表数据适合基于升序的日期或时间作为分区列。
简单来说，要考虑是否能从分区中获益，不要仅仅因为体积而进行分区。
------解决方案--------------------
1. 如题，假设有一张表A，存放了“北京”、“上海”、“苏州”、“南京”等city的信息，表中的数据量可能达到上万条，那么是否有必要将表A根据city拆分，每一个city建立一张表？
--> 没必要.
2. 我经常用到的操作有2个：第一，根据城市名查询记录“select [字段名] from A where city = ''城市名”；第二，根据城市名插入记录。如果A的记录条数会影响查询效率和插入效率，那么当记录条数达到多少量级的时候会使得效率较低？
-->
查询:在city字段上建索引即可.
插入:数据量不大,插入效率问题应可忽略.
------解决方案--------------------
若不是亿级别和管理上如归档的需求，别去折腾分区
不建议分表，无谓的增加程序判断处理
除非数据量、负荷真的超过单台性能极限，否则别分表（潜在地分机器）
------解决方案--------------------
好吧，我8楼的话有误。
在同时存在聚集索引的情况下，非聚集索引中存放的不是RID而是聚集索引的键值。
但是索引缓存在内存中，即使是两次定位也比通过全表扫描要快啊。
怎么会认为建索引反而慢了？