SQL数据库大字段查询问题
0
悬赏园豆：20
[已解决问题]
解决于 2014-08-05 10:22
问题现象：
数据表Product，有字段 FullDescription，类型 nvarchar(max)，记录有54条，在服务器本机查询，基本能闪出，但在LAN里的开发机器查询，则需要很长时间（有时几秒，有时两分钟甚至更长）。
开始，以为是LAN网络问题，经排查，不是这个原因（虽然处理后有所改善）。
又：查询别的表（即便有nvarchar(max)类型，记录也更多）都没发生这个现象，因此分析问题可能是这个表Product坏了导致的，便新建一个完全相同的表ProductNew，并复制数据，再查询，问题依然。
因此，分析可能问题出现在字段的类型及内容上。逐字段跟踪查询，确定导致问题的字段是类型为nvarchar(max)的字段FullDescription。
分析该字段数据，检查到内容长度（nvarchar）有好几个M的记录，把超过1M的记录屏蔽，性能大大提高，把超过700K的记录再屏蔽，数据即便在开发机器上也是闪出。
求助：
1、这个问题在早前应该是存在，只是没这么严重（估计也就10秒以内，下午发现特严重，到分钟级别），请问突然性能降低的原因是什么？有什么办法解决？
2、作为100M的LAN，网络性能有差到分钟级别吗？
3、对于类似的nvarchar(max)类型字段，既然是max了，数据超过1M的情况肯定在所难免，该怎么有效解决？
谢谢！
最佳答案
0
如果不是每次都需要FullDescription，可以采用主从表设计。
还有，你这个字段是什么类型的？文本？这么大的字段类型，感觉不太合理。可以考虑做成文件，然后存储路径。
收获园豆：4
使用的是max，只存储文本。
@519740105: 你这文本太大了。是否每次都需要读取那么大的文本，这么大的文本，应该受到网络影响很大。还是建议搞成文件，存路径。
@幻天芒: 大数据倒是有专门的存储。不过呢，这里，我想修改成ntext，在研究EF怎么使用NTEXT。
@519740105: NText是05的字段类型，和nvarchar(max)效果一样的呀。主要是你的字段内容太大。
@幻天芒: 恩。修改为ntext后问题依然。
@519740105: 还没见过，单子段几M大小的。
其他回答(4)
0
能缓存不。
收获园豆：4
0
这个就是网络传输问题,基本上这么长的文本数据已经可以用单独的文件系统处理了.不应该放数据库了
收获园豆：4
赞同，要知道数据库是以页为单位的，每页为8kb,而跨页的开销是很大的。
0
你测试的时候是用的 SQL Server Management Studio 吗？
收获园豆：4
对。用的是IDE环境。
@519740105: 你 select 出的 54 条记录，大概有多少 MB ？
@Launcher: 没统计，只是其中的8条数据大概有12M+，16条有15M+
@519740105: 也就是 12M + 15M ，大概 30MB 左右。100MB网卡峰值传输大概在 12 MB 左右，也就是说就算独占带宽，大概也需要 3 秒左右才能传输完全部的数据。如果超过这个时间太多，最常见的原因是网络繁忙，没能独占带宽。
@Launcher: 恩。
0
分表吧，把这个大字段的内容存到另一个表里，一般情况是直接查主表数据就完了，需要查这个大字段的时候，去子表里面查。
淘宝也是有个产品描述的大字段就是采用分表的方式把这个大字段单独存在另一个表中。
收获园豆：4
