If you decide to put your pictures into a sql Server table,I would strongly recommend using a separate table for storing those pictures – do not store the employee photo in the employee table – keep them in a separate table. That way,the Employee table can stay lean and mean and very efficient,assuming you don’t always need to select the employee photo,too,as part of your queries.
为什么？我是在表中的SQL Server only stores a pointer to some dedicated BLOB data structure的印象,所以为什么还要手动创建另一层间接？它是否真的显着改善了性能？如果是,为什么？
解决方法
他们造成的主要问题(对我来说)是索引.将XML与查询计划一起使用,因为每个人都有了,我们制作一张桌子：
SELECT TOP 1000 ID = IDENTITY(INT,1,1),deq.query_plan INTO dbo.index_test FROM sys.dm_exec_cached_plans AS dec CROSS APPLY sys.dm_exec_query_plan(dec.plan_handle) AS deq ALTER TABLE dbo.index_test ADD CONSTRAINT pk_id PRIMARY KEY CLUSTERED (ID)
它只有1000行,但是checking on the size ……
sp_BlitzIndex @DatabaseName = 'StackOverflow',@SchemaName = 'dbo',@TableName = 'index_test'
仅1000行就超过40 MB.假设你每1000行添加40 MB,那么很快就会变得非常难看.当你达到100万行时会发生什么？那里只有大约1 TB的数据.
现在,任何需要使用聚簇索引的查询都需要将所有BLOB数据读入内存说明：引用BLOB数据列时.
你能想到比存储BLOB更好的方法来使用sql Server内存吗？因为我当然可以.
将其扩展为非聚簇索引：
CREATE INDEX ix_noblob ON dbo.index_test (ID) CREATE INDEX ix_returnoftheblob ON dbo.index_test (ID) INCLUDE (query_plan)
您可以设计非聚簇索引以在很大程度上避免BLOB列,因此常规查询可以避免聚簇索引,但只要您需要BLOB列,就需要聚簇索引.
如果将其作为INCLUDED列添加到非聚簇索引以避免键查找方案,则最终会得到巨大的非聚簇索引：
他们造成的问题更多：
>如果有人运行SELECT *查询,他们将获得所有BLOB数据.
>它们占用备份和恢复空间,减慢速度
>他们放慢了DBCC CHECKDB的速度,因为我知道你正在检查腐败,对吧？
>如果你做任何索引维护,他们也会放慢速度.
希望这可以帮助！
