① sql lite如何减小体积
1.建表优化
SQLite的数据库本质文件读写操作，频繁操作打开和关闭是很耗时和浪费资源的；
优化方法事务机制：
这里要注意一点：事务的开启是要锁定DB的，其他对DB的写入操作都是无法成功的。
db.beginTransaction(); //手动设置开始事务
try {
//这里写你数据操作
db.setTransactionSuccessful();
//设置事务处理成功，不设置会自动回滚不提交
} catch (Exception e) {
} finaly {
db.endTransaction(); //提交
}
项目中不会把项目上万条数据存SQL里的，尽管android有SQLite。
那样处理起来非常慢，而且程序经常出现ANR。
打个比方：有200个城市，每个城市500条城市信息，你怎么创建表？
A：我创建一张表存10000条数据。
B：200张表，每张存500条数据。
C：我创建两张表，
一张存city，其实这张表只有1条数据；
Id(编号)，
Version（这200个城市更新版本用）
CityDate（200个城市xml格式字符串数据）。
另一张表存城市信息表：200条数据，每个城市一条数据
id（CityDate解析出城市对象对应的id）
Version（这500条城市信息更新版本用）
CityMessage（500条城市信息xml格式字符串数据）。
首先你给用户展示200城市（你只取了一条数据 200个城市xml格式字符串数据进行解析）
用户点击一个城市你显示500条记录（通过城市解析ID，取出城市信息表中对应500数据xml格式字符串数据进行解析）
这样做的好处：
（1）统一数据接口，无论你从网络上直接去数据，还是读本地缓存统一数据接口，xml
（2）数据进行排序，内存操作要快一些；
（3）其实这和自己写文件没什么区别，为什么还要用数据库那，这么做有利于程序版本更新升级数据
维护！
2.其他技巧
1） 相对于封装过的ContentProvider而言，使用原始SQL语句执行效率高，比如使用方法rawQuery、execSQL的执行效率比较高。
2） 对于需要一次性修改多个数据时，可以考虑使用SQLite的事务方式批量处理，我们定义SQLiteDatabase db对象，执行的顺序为
db.beginTransaction();
//这里处理数据添加，删除或修改的SQL语句
db.setTransactionSuccessful(); //这里设置处理成功
db.endTransaction(); //这句很重要，告诉数据库处理完成了，这时SQLite的底层会执行具体的数据操作。
3） 打好SQL语句的基础，对于查询，以及分配表的结构都十分重要
3.
一、影响查询性能的因素：
1． 对表中行的检索数目，越小越好
2． 排序与否。
3． 是否要对一个索引。
4． 查询语句的形式
二、几个查询优化的转换
1． 对于单个表的单个列而言，如果都有形如T.C=expr这样的子句，并且都是用OR操作符连接起来，形如： x = expr1 OR expr2 = x OR x = expr3 此时由于对于OR，在SQLite中不能利用索引来优化，所以可以将它转换成带有IN操作符的子句：x IN(expr1,expr2,expr3)这样就可以用索引进行优化，效果很明显，但是如果在都没有索引的情况下OR语句执行效率会稍优于IN语句的效率。
2． 如果一个子句的操作符是BETWEEN，在SQLite中同样不能用索引进行优化，所以也要进行相应的等价转换： 如：a BETWEEN b AND c可以转换成：(a BETWEEN b AND c) AND (a>=b) AND (a<=c)。 在上面这个子句中， (a>=b) AND (a<=c)将被设为dynamic且是(a BETWEEN b AND c)的子句，那么如果BETWEEN语句已经编码，那么子句就忽略不计，如果存在可利用的index使得子句已经满足条件，那么父句则被忽略。
3． 如果一个单元的操作符是LIKE，那么将做下面的转换：x LIKE ‘abc%’，转换成：x>=‘abc’ AND x<‘abd’。因为在SQLite中的LIKE是不能用索引进行优化的，所以如果存在索引的话，则转换后和不转换相差很远，因为对LIKE不起作用，但如果不存在索引，那么LIKE在效率方面也还是比不上转换后的效率的。
三、 几种查询语句的处理（复合查询）
1．查询语句为：<SelectA> <operator> <selectB> ORDER BY <orderbylist> ORDER BY 执行方法： is one of UNION ALL, UNION, EXCEPT, or INTERSECT. 这个语句的执行过程是先将selectA和selectB执行并且排序，再对两个结果扫描处理，对上面四种操作是不同的，将执行过程分成七个子过程：
outA: 将selectA的结果的一行放到最终结果集中
outB: 将selectA的结果的一行放到最终结果集中(只有UNION操作和UNION ALL操作，其它操作都不放入最终结果集中)
AltB: 当selectA的当前记录小于selectB的当前记录
AeqB: 当selectA的当前记录等于selectB的当前记录
AgtB: 当selectA的当前记录大于selectB的当前记录
EofA: 当selectA的结果遍历完
EofB: 当selectB的结果遍历完
四、子查询扁平化
例子：SELECT a FROM (SELECT x+y AS a FROM t1 WHERE z<100) WHERE a>5
对这个SQL语句的执行一般默认的方法就是先执行内查询，把结果放到一个临时表中，再对这个表进行外部查询，这就要对数据处理两次，另外这个临时表没有索引，所以对外部查询就不能进行优化了，如果对上面的SQL进行处理后可以得到如下SQL语句：SELECT x+y AS a FROM t1 WHERE z<100 AND a>5，这个结果显然和上面的一样，但此时只需要对数据进行查询一次就够了，另外如果在表t1上有索引的话就避免了遍历整个表。
运用flatten方法优化SQL的条件：
1.子查询和外查询没有都用集函数
2.子查询没有用集函数或者外查询不是个表的连接
3.子查询不是一个左外连接的右操作数
4.子查询没有用DISTINCT或者外查询不是个表的连接
5.子查询没有用DISTINCT或者外查询没有用集函数
6.子查询没有用集函数或者外查询没有用关键字DISTINCT
7.子查询有一个FROM语句
8.子查询没有用LIMIT或者外查询不是表的连接
9.子查询没有用LIMIT或者外查询没有用集函数
10.子查询没有用集函数或者外查询没用LIMIT
11.子查询和外查询不是同时是ORDER BY子句
12.子查询和外查询没有都用LIMIT
13.子查询没有用OFFSET
14.外查询不是一个复合查询的一部分或者子查询没有同时用关键字ORDER BY和LIMIT
15.外查询没有用集函数子查询不包含ORDER BY
16.复合子查询的扁平化：子查询不是一个复合查询，或者他是一个UNION ALL复合查询，但他是都由若干个非集函数的查询构成，他的父查询不是一个复合查询的子查询，也没有用集函数或者是DISTINCT查询，并且在FROM语句中没有其它的表或者子查询，父查询和子查询可能会包含WHERE语句，这些都会受到上面11、12、13条件的限制。
SELECT a+1 FROM (
SELECT x FROM tab
UNION ALL
SELECT y FROM tab
UNION ALL
SELECT abs(z*2) FROM tab2
) WHERE a!=5 ORDER BY 1
转换为：
SELECT x+1 FROM tab WHERE x+1!=5
UNION ALL
SELECT y+1 FROM tab WHERE y+1!=5
UNION ALL
SELECT abs(z*2)+1 FROM tab2 WHERE abs(z*2)+1!=5
ORDER BY 1
五、连接查询
在返回查询结果之前，相关表的每行必须都已经连接起来，在SQLite中，这是用嵌套循环实现的，在早期版本中，最左边的是最外层循环，最右边的是最内层循环，连接两个或者更多的表时，如果有索引则放到内层循环中，也就是放到FROM最后面，因为对于前面选中的每行，找后面与之对应的行时，如果有索引则会很快，如果没有则要遍历整个表，这样效率就很低，但在新版本中，这个优化已经实现。
优化的方法如下：
对要查询的每个表，统计这个表上的索引信息，首先将代价赋值为SQLITE_BIG_DBL（一个系统已经定义的常量）：
1、如果没有索引，则找有没有在这个表上对rowid的查询条件：
如果有Rowid=EXPR，如果有的话则返回对这个表代价估计，代价计为零，查询得到的记录数为1，并完成对这个表的代价估计。
如果没有Rowid=EXPR 但有rowid IN (...)，而IN是一个列表，那么记录返回记录数为IN列表中元素的个数，估计代价为NlogN,
如果IN不是一个列表而是一个子查询结果，那么由于具体这个子查询不能确定，所以只能估计一个值，返回记录数为100，代价为200。
如果对rowid是范围的查询，那么就估计所有符合条件的记录是总记录的三分之一，总记录估计为1000000，并且估计代价也为记录数。
如果这个查询还要求排序，则再另外加上排序的代价NlogN
如果此时得到的代价小于总代价，那么就更新总代价，否则不更新。
2、如果WHERE子句中存在OR操作符，那么要把这些OR连接的所有子句分开再进行分析。
如果有子句是由AND连接符构成，那么再把由AND连接的子句再分别分析。
如果连接的子句的形式是X<op><expr>，那么就再分析这个子句。
接下来就是把整个对OR操作的总代价计算出来。
如果这个查询要求排序，则再在上面总代价上再乘上排序代价NlogN
如果此时得到的代价小于总代价，那么就更新总代价，否则不更新。
3、如果有索引，则统计每个表的索引信息，对于每个索引：
先找到这个索引对应的列号，再找到对应的能用到（操作符必须为=或者是IN（…））这个索引的WHERE子句，如果没有找到，则退出对每个索引的循环，如果找到，则判断这个子句的操作符是什么，如果是=，那么没有附加的代价，如果是IN（sub-select），那么估计它附加代价inMultiplier为25，如果是IN（list），那么附加代价就是N（N为list的列数）。
再计算总的代价和总的查询结果记录数和代价。
nRow = pProbe->aiRowEst * inMultiplier;/*计算行数*/
cost = nRow * estLog(inMultiplier);/*统计代价*/
如果找不到操作符为=或者是IN（…）的子句，而是范围的查询，那么同样只好估计查询结果记录数为nRow/3，估计代价为cost/3。
同样，如果此查询要求排序的话，再在上面的总代价上加上NlogN
如果此时得到的代价小于总代价，那么就更新总代价，否则不更新。
4、通过上面的优化过程，可以得到对一个表查询的总代价
再对第二个表进行同样的操作，这样如此直到把FROM子句中所有的表都计算出各自的代价，最后取最小的，这将作为嵌套循环的最内层，依次可以得到整个嵌套循环的嵌套顺序，此时正是最优的，达到了优化的目的。
5、所以循环的嵌套顺序不一定是与FROM子句中的顺序一致，因为在执行过程中会用索引优化来重新排列顺序。
六、索引
在SQLite中，有以下几种索引：
1) 单列索引
2) 多列索引
3) 唯一性索引
4) 对于声明为：INTEGER PRIMARY KEY的主键来说，这列会按默认方式排序，所以虽然在数据字典中没有对它生成索引，但它的功能就像个索引。所以如果在这个主键上在单独建立索引的话，这样既浪费空间也没有任何好处。
运用索引的注意事项：
1) 对于一个很小的表来说没必要建立索引
2) 在一个表上如果经常做的是插入更新操作，那么就要节制使用索引
3) 也不要在一个表上建立太多的索引，如果建立太多的话那么在查询的时候SQLite可能不会选择最好的来执行查询，一个解决办法就是建立聚蔟索引。
索引的运用时机：
1) 操作符：=、>、<、IN等
2) 操作符BETWEEN、LIKE、OR不能用索引，
如BETWEEN：SELECT * FROM mytable WHERE myfield BETWEEN 10 and 20;
这时就应该将其转换成：
SELECT * FROM mytable WHERE myfield >= 10 AND myfield <= 20;
此时如果在myfield上有索引的话就可以用了，大大提高速度
再如LIKE：SELECT * FROM mytable WHERE myfield LIKE 'sql%';
此时应该将它转换成：
SELECT * FROM mytable WHERE myfield >= 'sql' AND myfield < 'sqm';
此时如果在myfield上有索引的话就可以用了，大大提高速度
再如OR：SELECT * FROM mytable WHERE myfield = 'abc' OR myfield = 'xyz';
此时应该将它转换成：
SELECT * FROM mytable WHERE myfield IN ('abc', 'xyz');
此时如果在myfield上有索引的话就可以用了，大大提高速度
3) 有些时候索引都是不能用的，这时就应该遍历全表（程序演示）
② MSSQL\Data 下的文件为什么会很大该如何处理
很大是因为数据记录很多。
数据库可以通过优化减小体积，但是减小的大小很有限。
因此，一般没必要处理，因为那些本来就是你需要的数据。除非你不要了。
③ SQL数据库太大怎么办
--1.日常要做数据库压缩
--压缩日志及数据库文件大小
/*--特别注意
请按步骤进行,未进行前面的步骤,请不要做后面的步骤
否则可能损坏你的数据库.
--*/
1.清空日志
DUMP TRANSACTION 库名 WITH NO_LOG
2.截断事务日志：
BACKUP LOG 数据库名 WITH NO_LOG
3.收缩数据库文件(如果不压缩,数据库的文件不会减小
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
也可以用SQL语句来完成
--收缩数据库
DBCC SHRINKDATABASE(客户资料)
--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles
DBCC SHRINKFILE(1)
4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行)
a.分离数据库:
企业管理器--服务器--数据库--右键--分离数据库
b.在我的电脑中删除LOG文件
c.附加数据库:
企业管理器--服务器--数据库--右键--附加数据库
此法将生成新的LOG，大小只有500多K
或用代码：
下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。
a.分离
EXEC sp_detach_db @dbname = 'pubs'
b.删除日志文件
c.再附加
EXEC sp_attach_single_file_db @dbname = 'pubs',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'
5.为了以后能自动收缩,做如下设置:
企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"
--SQL语句设置方式:
EXEC sp_dboption '数据库名', 'autoshrink', 'TRUE'
6.如果想以后不让它日志增长得太大
企业管理器--服务器--右键数据库--属性--事务日志
--将文件增长限制为xM(x是你允许的最大数据文件大小)
--SQL语句的设置方式:
alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)
④ mssql数据库太大怎么压缩
数据库在使用一段时间后，时常会出现因数据删除而造成数据库中空闲空间太多的情况，这时就需要减少分配给数据库文件和事务日志文件的磁盘空间，以免浪费磁盘空间。当数据库中没有数据时，可以修改数据库文件属性直接改变其占用空间，但当数据库中有数据时，这样做会破坏数据库中的数据，因此需要使用压缩的方式来缩减数据库空间。可以在数据库属性选项中选择“Auto shrink”选项，让系统自动压缩数据库，也可以用人工的方法来压缩。人工压缩数据库有以下两种方式：
1、用Enterprise Manager 压缩数据库
在Enterprise Manager 中在所要压缩的数据库上单击右键，从快捷菜单中的“所有任务（All Tasks）”中选择“Shrink Database（压缩数据库）”选项
、用Transact-SQL 命令压缩数据库
可以使用DBCC SHRINKDATABASE 和DBCC SHRINKFILE 命令来压缩数据库。其中DBCC SHRINKDATABASE 命令对数据库进行压缩，DBCC SHRINKFILE 命令对数据库中指定的文件进行压缩。
（1） DBCC SHRINKDATABASE
DBCC SHRINKDATABASE 命令语法如下：
DBCC SHRINKDATABASE (database_name [, target_percent]
[, {NOTRUNCATE | TRUNCATEONLY}] )
各参数说明如下：
target_percent 指定将数据库压缩后，未使用的空间占数据库大小的百分之几。如果指定的百分比过大，超过了压缩前未使用空间所占的比例，则数据库不会被压缩。并且压缩后的数据库不能比数据库初始设定的容量小。
NOTRUECATE
将数据库缩减后剩余的空间保留在数据库，中不返还给操作系统。如果不选择此选项，则剩余的空间返还给操作系统。
TRUNCATEONLY
将数据库缩减后剩余的空间返还给操作系统。使用此命令时SQL Server 将文件缩减到最后一个文件分配，区域但不移动任何数据文件。选择此项后，target_percent 选项就无效了。
压缩数据库mytest 的未使用空间为数据库大小的20%。
dbcc shrinkdatabase (mytest, 20)
运行结果如下：
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
(2) DBCC SHRINKFILE
DBCC SHRINKFILE 命令压缩当前数据库中的文件。其语法如下：
DBCC SHRINKFILE ( {file_name | file_id }
{ [, target_size] |
[, {EMPTYFILE | NOTRUNCATE | TRUNCATEONLY}] } )
各参数说明如下：
file_id
指定要压缩的文件的鉴别号（Identification number， 即ID）。文件的ID 号可以通过 FILE_ID（）函数或如本章前面所讲述的Sp_helpdb 系统存储过程来得到。
target_size
指定文件压缩后的大小。以MB 为单位。如果不指定此选项，SQL Server 就会尽最大可能地缩减文件。
EMPTYFILE
指明此文件不再使用，将移动所有在此文件中的数据到同一文件组中的其它文件中去。执行带此参数的命令后，此文件就可以用ALTER DATABASE 命令来删除了。
其余参数NOTRUNCATE 和TRUNCATEONLY 与DBCC SHRINKDATABASE 命令中的含义相同。
例6-15: 压缩数据库mydb 中的数据库文件mydb_data2 的大小到1MB。 use mydb dbcc shrinkfile (mydb_data2, 1)
⑤ SQL数据库文件太大怎么处理
如果是MSSQL在任务里选数据库收缩，可以缩小很多。
不然只能把数据导出来减小数据库了。
⑥ SQL 数据库收缩问题
SQL数据库收缩一种是自动收缩：在数据库属性选项里，将自动收缩设置为True
另外一种是手动收缩：调节最大可用空间到合适的值根据具体的需求进行设置，一般设置为40%为宜。
⑦ sql数据库日志文件过大怎么办
经过几个小时的测试，最有用的方法如下：
停止数据库MSSQL实
复制数据库目标库文件('***.mdf')重新命名执行如下SQL语句，注意修改正确的库名
EXECsp_attach_single_file_db@dbname='库名',
@physname='D:_50.MSSQLSERVERMSSQLDATA库名.mdf'数据库属性/文件/限制文件增长
数据库属性/选项/设置数据库收缩为[自动收缩]
⑧ 如何减肥SQL数据库的容量
/*--特别注意 请按步骤进行,未进行前面的步骤,请不要做后面的步骤 否则可能损坏你的数据库. 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. --*/ --下面的所有库名都指你要处理的数据库的库名 1.清空日志 DUMP TRANSACTION 库名 WITH NO_LOG 2.截断事务日志： BACKUP LOG 库名 WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDATABASE(库名) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行) a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库 此法将生成新的LOG，大小只有500多K 或用代码： 下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。 a.分离 EXEC sp_detach_db @dbname = '库名' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '库名', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf' 5.为了以后能自动收缩,做如下设置: 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EXEC sp_dboption '库名', 'autoshrink', 'TRUE' 6.如果想以后不让它日志增长得太大 企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 库名 modify file(name=逻辑文件名