甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
sql sever中照片用image数据类型。
目前创新互联已为上千家的企业提供了网站建设、域名、雅安服务器托管、网站托管、企业网站设计、盐边网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
sql sever数据库中的Image数据类型可以进行数据图片的存储。保存的是二进制字节，所以写入sql sever数据库Image数据类型时，sql sever数据库自动将图片转换成二进制字节后存入。读取的时候，将二进制再转换成图片从sql sever数据库中输出显示到页面或者程序中。
扩展资料：
如果SQL Server是缺省安装时， IMAGE类型字段是有长度限制，用来存储图片大小不超过2g的图片。缺点是占用了很大的数据存储空间。但是对于之前的存储物理路径来说读取图片和存储图片方便了很多。
一般开发中，照片等二进制的文件并不保存在数据库中。而是保存在服务器的特定目录中，然后在数据库中记录一下这个具体路径和文件名。
毫无疑问，给表添加索引是有好处的，你要做的大部分工作就是维护索引，在数据更改期间索引可能产生碎片，所以一些维护是必要的。碎片可能是你查询产生性能问题的来源。
那么到底什么是索引碎片呢？索引碎片实际上有2种形式：外部碎片和内部碎片。不管哪种碎片基本上都会影响索引内页的使用。这也许是因为页的逻辑顺序错误（即外部碎片）或每页存储的数据量少于数据页的容量（内部错误）。无论索引产生了哪种类型的碎片，你都会因为它而面临查询的性能问题。
外部碎片
当 索引页不在逻辑顺序上时就会产生外部碎片。索引创建时，索引键按照逻辑顺序放在一组索引页上。当新数据插入索引时，新的键可能放在存在的键之间。为了让新 的键按照正确的顺序插入，可能会创建新的索引页来存储需要移动的那些存在的键。这些新的索引页通常物理上不会和那些被移动的键原来所在的页相邻。创建新页 的过程会引起索引页偏离逻辑顺序。
下面的例子将比实际的言论更加清晰的解释这个概念。
假定在任何另外的数据插入你的表之前存在索引上的结构如下
（注：下面图片里应该是7和8，原文里是6和8）：
INSERT语句往索引里添加新的数据，假定添加的是5。INSERT将引起新页创建，为了给5在原来的页上留出空间，7和8被移到了新页上。这个创建将引起索引页偏离逻辑顺序。
在有特定搜索或者返回无序结果集的查询的情况下，偏离顺序的索引页不会引起问题。对于返回有序结果集的查询，搜索那些无序的索引页需要进行额外的处理。有序结果集的例子如查询返回4到10之间的记录。为了返回7和8，查询不得不进行额外的页切换。虽然一个额外的页切换在一个长时间运行里是无关紧要的，然而想象一下一个有好几百页偏离顺序的非常大的表的情形。
内部碎片
当索引页没有用到最大量时就产生了内部碎片。虽然在一个有频繁数据插入的应用程序里这也许有帮助，然而设置一个fill factor（填充因子）会在索引页上留下空间，服务器内部碎片会导致索引尺寸增加，从而在返回需要的数据时要执行额外的读操作。这些额外的读操作会降低查询的性能。
怎样确定索引是否有碎片？
SQLServer提供了一个数据库命令――DBCC SHOWCONTIG――来确定一个指定的表或索引是否有碎片。
DBCC SHOWCONTIG
数据库平台命令，用来显示指定的表的数据和索引的碎片信息。
DBCC SHOWCONTIG 权限默认授予 sysadmin固定服务器角色或 db_owner 和 db_ddladmin固定数据库角色的成员以及表的所有者且不可转让。
语法（SQLServer2000）
DBCC SHOWCONTIG
[ ( { table_name | table_id| view_name | view_id }
[ , index_name | index_id ]
)
]
[ WITH { ALL_INDEXES
| FAST [ , ALL_INDEXES ]
| TABLERESULTS [ , { ALL_INDEXES } ]
[ , { FAST | ALL_LEVELS } ]
}
]
语法（SQLServer7.0）
DBCC SHOWCONTIG
[ ( table_id [,index_id ]
)
]
示例：
显示数据库里所有索引的碎片信息
SET NOCOUNT ON
USE pubs
DBCC SHOWCONTIG WITH ALL_INDEXES
GO
显示指定表的所有索引的碎片信息
SET NOCOUNT ONUSE pubs
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
GO
显示指定索引的碎片信息
SET NOCOUNT ON
USE pubs
DBCC SHOWCONTIG (authors,aunmind)
GO
结果集
DBCC SHOWCONTIG将返回扫描页数、扫描扩展盘区数、遍历索引或表的页时，DBCC 语句从一个扩展盘区移动到其它扩展盘区的次数、每个扩展盘区的页数、扫描密度（最佳值是指在一切都连续地链接的情况下，扩展盘区更改的理想数目）。
DBCC SHOWCONTIG 正在扫描 'authors' 表...
表: 'authors'（1977058079）；
索引 ID: 1，数据库 ID: 5
已执行 TABLE 级别的扫描。
- 扫描页数.....................................: 1
- 扫描扩展盘区数...............................: 1
- 扩展盘区开关数...............................: 0
- 每个扩展盘区上的平均页数.....................: 1.0
- 扫描密度［最佳值:实际值］....................: 100.00%［1:1］
- 逻辑扫描碎片.................................: 0.00%
- 扩展盘区扫描碎片.............................: 0.00%
- 每页上的平均可用字节数.......................: 6010.0
- 平均页密度（完整）...........................: 25.75%
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
寻找什么
扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。
扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。
扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。
每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。
扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。
逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。
扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。
每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。
平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。
备注
DBCC SHOWCONTIG实际上仅对那些大表有用。小表显示的结果根本不符合正常标准，因为他们也许没有由多于8个的页面组成。你在查看小表上执行DBCC SHOWCONTIG的结果时应该忽略一些结果。在处理小表时只需关心扩展盘区开关数、逻辑扫描碎片、每页上的平均可用字节数、平均页密度（完整）。
DBCC SHOWCONTIG默认输出的结果是：扫描页数、扫描扩展盘区数、扩展盘区开关数、每个扩展盘区上的平均页数、扫描密度［最佳值:实际值］、逻辑扫描碎片、扩展盘区扫描碎片、每页上的平均可用字节数、平均页密度（完整）。可以用FAST和TABLERESULTS选项来控制这个输出结果。
FAST选项指定执行索引的快速扫描，输出结果是最小的，该选项不读索引的叶或数据页且只返回扫描页数、扫描扩展盘区数、扫描密度［最佳值:实际值］、逻辑扫描碎片。
TABLERESULTS选项将用行集的形式显示信息，将返回扩展盘区开关数、扫描密度［最佳值:实际值］、逻辑扫描碎片、扩展盘区扫描碎片、每页上的平均可用字节数、平均页密度（完整）。
如果既指定FAST选项又指定TABLERESULTS选项，那么将返回对象名、对象ID、索引名、索引ID，页数、扩展盘区开关数、扫描密度［最佳值:实际值］和逻辑扫描碎片。
ALL_INDEXES选项将显示指定表和试图的所有索引的结果，即使指定了一个索引。
ALL_LEVELS选项指定是否为所处理的每个索引的每个级别产生输出（默认只输出索引的页级或表数据级的结果），并且只能与 TABLERESULTS 选项一起使用。
解决碎片问题
一旦你确定表或索引有碎片问题，那么你有4个选择去解决那些问题：
删除并重建索引
使用DROP_EXISTING子句重建索引
执行DBCC DBREINDEX
执行DBCC INDEXDEFRAG
尽管每一个技术都能达到你整理索引碎片的最终目的，但各有各的优缺点。
删除并重建索引
用DROP INDEX和CREATE INDEX或ALTER TABLE来 删除并重建索引有些缺陷包括在删除重建期间索引会消失。在索引删除重建时，对于查询它不在可用，查询性能也许会受到明显的影响，直到重建索引为止。另一个 潜在的缺陷是当都请求索引的时候会引起阻塞，直到重建索引为止。通过其他的处理也能解决阻塞，就是索引被使用的时候不删除索引。另一个主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引时会引起非聚集索引重建两次。删除聚集索引时非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。
删除并重建索引的确有一个好处就是通过重新排序索引页，使索引页紧凑并删除不需要的索引页来完全重建索引。你也许需要考虑那些内部和外部碎片都很高的情况下才使用，以使那些索引回到它们应该在的位置。
使用DROP_EXISTING子句重建索引
为了避免在重建聚集索引时表上的非聚集索引重建两次，可以使用带DROP_EXISTING子句的CREATE INDEX语句。这个子句会保留聚集索引键值，以避免非聚集索引重建两次。和删除并重建索引一样，该方法也可能会引起阻塞和索引消失的问题。该方法的另一个缺陷是也强迫你去分别发现和修复表上的每一个索引。 除了和上一个方法一样的好处之外，该方法的好处是不必重建非聚集索引两次。这样可以对那些带约束的索引提供正确的索引定义以符合约束的要求。 执行DBCC DBREINDEX DBCC DBREINDEX类似于第二种方法，但它物理地重建索引，允许SQLServer给索引分配新页来减少内部和外部碎片。DBCC DBREINDEX也能动态的重建带约束的索引，不象第二种方法。 DBCC DBREINDEX的缺陷是会遇到或引起阻塞问题。DBCC DBREINDEX是作为一个事务来运行的，所以如果在完成之前中断了，那么你会丢失所有已经执行过的碎片。 执行DBCC INDEXDEFRAG DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引键的逻辑顺序，通过重新整理索引里存在的叶页来减少外部碎片，通过压缩索引页里的行然后删除那些由此产生的不需要的页来减少内部碎片。它不会遇到阻塞问题但它的结果没有其他几个方法彻底。这是因为DBCC INDEXDEFRAG跳过了锁定的页且不使用任何新页来重新排序索引。如果索引的碎片数量大的话你也许会发现DBCC INDEXDEFRAG比重建索引花费的时间更长。DBCC INDEXDEFRAG比其他方法的确有好处的是在其他过程访问索引时也能进行碎片整理，不会引起其他方法的阻塞问题。
你只需要在SQL-SERVER上记录这些图片的路径，前台是个js插件，用程序控制输出等量的图片就可以了。
以下有几款迁移工具的对比，可以参考，比较推荐DB2DB.
软件易用性主要是指软件在导入前的配置是否容易。由于很多软件设计是面向程序员而非一般的数据库管理人员、甚至是普通的应用程序实施人员，而这一类人员很多时候并没有数据源配置经验。因为一些使用 ODBC 或者 ADO 进行配置的程序往往会让这类用户造成困扰（主要是不知道应该选择什么类型的数据库驱动程序）。下面让我们看看四个工具的设计界面：
1、SQLyog
SQLyog 使用的是古老的 ODBC 连接，但对于新一代的程序来说，这种方式的非常的不熟悉并且不容易使用，并且必须要求本机安装好相应的数据库的 ODBC 驱动程序（SQL Server 一般自带好）。
2、Navicat Premium
NavicatPremium是四个应用工具中设计最不人性化的一个：从上图怎么也想像不到要点按那个小按钮来添加一个新的连接，并且这个连接设置不会保存，每次导入时都必须重新设置。NavicatPremium使用的是比 ODBC 稍先进的 ADO 设置方式（199X年代的产物），但使用上依然是针对老一代的程序员。
3、Mss2sql
Mss2sql 是最容易在百度上搜索出来的工具，原因之一是它出现的时间较早。
Mss2sql由于是很有针对性的从 SQLServer 迁移到 MySQL，因为界面使用了操作向导设计，使用非常容易。同时在设置的过程中，有非常多的选项进行细节调整，可以感觉到软件经过了相当长一段时间的使用渐渐完善出来的。
4、DB2DB
DB2DB 由于是由国人开发，因此无论是界面还是提示信息，都是全程汉字。另外，由于 DB2DB 在功能上很有针对性，因为界面设计一目了然和易使用。和 mss2sql 一样， DB2DB 提供了非常多的选项供用户进行选择和设置。
三、处理速度和内存占用评测
在本评测前，本人的一位资深同事曾经从网上下载了某款迁移软件，把一个大约2500万记录数的数据表转送到阿里云 MySQL，结果经过了三天三夜（好在其中两天是星期六和星期日两个休息日）都未能迁移过来。因此这一次需要对这四个工具的处理速度作一个详细的测试。
考虑到从 SQL Server 迁移到 MySQL 会出现两种不同的场景：
从 SQL Server 迁移到本地 MySQL 进行代码测试和修改；
从 SQL Server 迁移到云端 MySQL 数据库正式上线使用；
以下为测试过程中的截图：
1、SQLyog
请点击输入图片描述
2、Navicat Premium
请点击输入图片描述
请点击输入图片描述
注意：我们在测试 Navicat Premium 迁移到 MySQL 时发现，对于 SQL Server 的 Money 类型支持不好（不排除还有其它的数据类型支持不好）。Money 类型字段默认的小数位长度为 255，使得无法创建数据表导致整个测试无法成功，需要我们逐张表进行表结构修改才能完成测试过程。
Navicat Premium 的处理速度属于中等，不算快也不算慢，但 CPU 占用还有内存占用都处于高位水平。不过以现在的电脑硬件水平来说，还是可以接受。但 CPU 占用率太高，将使得数据在导入的过程中，服务器不能用于其它用途。
3、Mss2sql
Mss2sql 并没有提供计时器，因此我们使用人工计时的方法，整个过程处理完毕大于是 726 秒。Mss2sql 的 CPU 占用率相对其它工具来说较高，但仍属于可以接受的范围之内。
4、DB2DB
请点击输入图片描述
DB2DB 同样迁移 300万数据时，仅仅使用了 2 分 44 秒，这个速度相当惊人。不过最后的结果出现一个 BUG，就是提示了转换成功，但后面的进度条却没有走完（在后面的数据完整性评测中，我们验证了数据其实是已经全部处理完毕了）。