㈠ 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) 有些时候索引都是不能用的，这时就应该遍历全表（程序演示）
㈡ php+mysql优化，百万至千万级快速分页mysql性能到底能有多高
php+Mysql 优化，百万至千万级快速分页
MySql 性能到底能有多高？用了php半年多，真正如此深入的去思考这个问题还是从前天开始。有过痛苦有过绝望，到现在充满信心！MySql 这个数据库绝对是适合dba级的高手去玩的，一般做一点1万篇新闻的小型系统怎么写都可以，用xx框架可以实现快速开发。可是数据量到了10万，百万至千万，他的性能还能那么高吗？一点小小的失误，可能造成整个系统的改写，甚至更本系统无法正常运行！好了，不那么多废话了。用事实说话，看例子：
数据表 collect ( id, title ,info ,vtype) 就这4个字段，其中 title 用定长，info 用text, id 是逐渐，vtype是tinyint，vtype是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据，填充10万篇新闻。
最后collect 为 10万条记录，数据库表占用硬盘1.6G。OK ,看下面这条sql语句：
select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的
select id,title from collect limit 90000,10; 从9万条开始分页，结果？
8-9秒完成，my god 哪出问题了？？？？其实要优化这条数据，网上找得到答案。看下面一条语句:
select id from collect order by id limit 90000,10; 很快，0.04秒就OK。为什么？因为用了id主键做索引当然快。网上的改法是：
select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;
这就是用了id做索引的结果。可是问题复杂那么一点点，就完了。看下面的语句
select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！
到了这里我相信很多人会和我一样，有崩溃感觉！vtype 做了索引了啊？怎么会慢呢？vtype做了索引是不错，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，从9万开始，那就是0.05*90=4.5秒的速度了。和测试结果8-9秒到了一个数量级。从这里开始有人提出了分表的思路，这个和discuz 论坛是一样的思路。思路如下：
建一个索引表： t (id,title,vtype) 并设置成定长，然后做分页，分页出结果再到 collect 里面去找info 。 是否可行呢？实验下就知道了。
10万条记录到 t(id,title,vtype) 里，数据表大小20M左右。用
select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。为什么会这样呢？我猜想是因为collect 数据太多，所以分页要跑很长的路。limit 完全和数据表的大小有关的。其实这样做还是全表扫描，只是因为数据量小，只有10万才快。OK，来个疯狂的实验，加到100万条，测试性能。
加了10倍的数据，马上t表就到了200多M，而且是定长。还是刚才的查询语句，时间是0.1-0.2秒完成！分表性能没问题？错！因为我们的limit还是9万，所以快。给个大的，90万开始
select id from t where vtype=1 order by id limit 900000,10; 看看结果，时间是1-2秒！
why 分表了时间还是这么长，非常之郁闷！有人说定长会提高limit的性能，开始我也以为，因为一条记录的长度是固定的，mysql 应该可以算出90万的位置才对啊？ 可是我们高估了mysql 的智能，他不是商务数据库，事实证明定长和非定长对limit影响不大？怪不得有人说 discuz到了100万条记录就会很慢，我相信这是真的，这个和数据库设计有关！
难道MySQL 无法突破100万的限制吗？？？到了100万的分页就真的到了极限？？？
答案是： NO !!!! 为什么突破不了100万是因为不会设计mysql造成的。下面介绍非分表法，来个疯狂的测试！一张表搞定100万记录，并且10G 数据库，如何快速分页！
好了，我们的测试又回到 collect表，开始测试结论是： 30万数据，用分表法可行，超过30万他的速度会慢道你无法忍受！当然如果用分表+我这种方法，那是绝对完美的。但是用了我这种方法后，不用分表也可以完美解决！
答案就是：复合索引！有一次设计mysql索引的时候，无意中发现索引名字可以任取，可以选择几个字段进来，这有什么用呢？开始的select id from collect order by id limit 90000,10; 这么快就是因为走了索引，可是如果加了where 就不走索引了。抱着试试看的想法加了 search(vtype,id) 这样的索引。然后测试
select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！
再测试: select id ,title from collect where vtype=1 limit 90000,10; 非常遗憾，8-9秒，没走search索引！
再测试：search(id,vtype)，还是select id 这个语句，也非常遗憾，0.5秒。
综上：如果对于有where 条件，又想走索引用limit的，必须设计一个索引，将where 放第一位，limit用到的主键放第2位，而且只能select 主键！
完美解决了分页问题了。可以快速返回id就有希望优化limit ， 按这样的逻辑，百万级的limit 应该在0.0x秒就可以分完。看来mysql 语句的优化和索引时非常重要的！
好了，回到原题，如何将上面的研究成功快速应用于开发呢？如果用复合查询，我的轻量级框架就没的用了。分页字符串还得自己写，那多麻烦？这里再看一个例子，思路就出来了：
select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！
mygod ，mysql 的索引竟然对于in语句同样有效！看来网上说in无法用索引是错误的！
有了这个结论，就可以很简单的应用于轻量级框架了：
代码如下：
$db=dblink();
$db->pagesize=20;
$sql="select id from collect where vtype=$vtype";
$db->execute($sql);
$strpage=$db->strpage(); //将分页字符串保存在临时变量，方便输出
while($rs=$db->fetch_array()){
$strid.=$rs['id'].',';
}
$strid=substr($strid,0,strlen($strid)-1); //构造出id字符串
$db->pagesize=0; //很关键，在不注销类的情况下，将分页清空，这样只需要用一次数据库连接，不需要再开；
$db->execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");
< php while($rs=$db->fetch_array()): >
<tr>
<td$amp;>amp;$amp;nbsp;< php echo $rs['id']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['url']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['sTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['gTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['vtype']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;<a act=show&id=< php echo $rs['id']; $amp;>quot;$ target="_blank"$amp;>amp;$lt; php echo $rs['title']; $amp;>amp;$lt;/a$amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['tag']; $amp;>amp;$lt;/td>
</tr>
< php endwhile; >
</table>
< php
echo $strpage;
通过简单的变换，其实思路很简单：1）通过优化索引，找出id，并拼成 "123,90000,12000" 这样的字符串。2）第2次查询找出结果。
小小的索引+一点点的改动就使mysql 可以支持百万甚至千万级的高效分页！
通过这里的例子，我反思了一点：对于大型系统，PHP千万不能用框架，尤其是那种连sql语句都看不到的框架！因为开始对于我的轻量级框架都差点崩溃！只适合小型应用的快速开发，对于ERP,OA，大型网站，数据层包括逻辑层的东西都不能用框架。如果程序员失去了对sql语句的把控，那项目的风险将会成几何级数增加！尤其是用mysql 的时候，mysql 一定需要专业的dba 才可以发挥他的最佳性能。一个索引所造成的性能差别可能是上千倍！
PS: 经过实际测试，到了100万的数据，160万数据，15G表，190M索引，就算走索引，limit都得0.49秒。所以分页最好别让别人看到10万条以后的数据，要不然会很慢！就算用索引。经过这样的优化，mysql到了百万级分页是个极限！但有这样的成绩已经很不错，如果你是用sqlserver肯定卡死！而 160万的数据用 id in (str) 很快，基本还是0秒。如果这样，千万级的数据，mysql应该也很容易应付。
㈢ SQL Lite和mysql是不是一样
不一样，首先你应该说的是SQLite吧。我貌似没停过有SQL Lite这样的数据库。
SQLite是用于Android开发的，那么应该在Linux里也可以用到(自己没尝试在Linux下应用)。
刚刚查网络得知其可以在Windows/Linux/Unix平台应用.我在开发Android的使用使用SQLite觉得它的限制性很大，产生一个.db的文件。没有mysql/sqlserver/oracle/db2这些主流数据库好用。
mysql的话属于小型一点的数据库，兼容性强，Java/php/asp等语言跟mysql应用都很好。
㈣ php+mssql 和 php+mysql 优点缺点
一、PHP+MySql
优点：
1) MySql是一个快速、多线程、多用户的SQL数据库服务器。
2) MySql的核心程序采用完全的多线程编程。
3)MySql可运行在不同的操作系统下。
4) MySql有一个非常灵活而且安全的权限和口令系统。
5) MySql支持ODBC for Windows。
6)MySql支持大型的数据库。
7) MySql拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性。
8) 强大的查询功能。
9)PHP为MySql提供了强力支持，PHP中提供了一整套的MySql函数，对MySql进行了全方位的支持。
缺点：
比较的难学;
MySQL不完全支持陌生的关键词;
MySQL也缺乏一些存储程序的功能;
使用缺省的ip端口，但是有时候这些ip也会被一些黑客闯入;
使用myisam配置，如果你不慎损坏数据库，结果可能会导致所有的数据丢失;
二、PHP+MsSql
优点：
上手容易; 兼容性良好; 利于构筑"敏捷性商务";
缺点:
只能在windows 上运行，没有丝毫的开放性，操作系统的系统的稳定对数据库是十分重要的。
并行实施和共存模型并不成熟。很难处理日益增多的用户数和数据卷。伸缩性有限;
安全性方面，没有获得任何安全证书;
客户端支持及应用模式 ，是C/S结构，只支持windows客户，可以用ADO, DAO,OLEDB,
ODBC连接;
不是免费的;
数据不容易恢复;
㈤ php框架相对原生php影响性能或效率吗
影响不大。因为http的请求，会受到网络速度的限制。与此相比，程序内部实现造成的影响，可能是很微小的。目前流行的php框架有yii、ci等。用它们编写一个简单的程序，和不使用框架，运行速度几乎没有差别。但使用框架时也需注意一些问题。
一个网页响应速度，和其网站架构、HTML的结构和比较耗时的操作关系较大。
其中网站架构涉及硬件设备和应用程序分布式布署的问题，对性能影响最为显着。一些程序难以解决的性能瓶颈，要用架构设计去解决。比如数据库读写分离。
优化HTML结构也是优化网站的课题之一。更为简约的编码，可以节约带宽，也能加快浏览器渲染的速度。页面字节大小，是前端设计的重要指标。异步加载和代码压缩，是减少网页下载时间的重要手段。
程序比较耗时的操作，如数据库查询、图片处理、压缩文件等。其中数据库的因素较为普遍。这里要提到一个框架的问题。yii框架自带的数据库模型非常强大，有了它我们基本上不用写SQL语句。但是，它自己生成的SQL语句不一定是最佳的。为了保证网站性能，关键的查询需要自己把握。而且比较复杂的抽象，也会降低性能。它的官方文档中，也不建议在大型网站中使用模型。
综上，框架的特性要选择性地使用。使用前要仔细阅读文档。优化网站要考虑多种因素，而不是仅仅关心程序的实现。要杜绝对程序效率影响不大的＂微优化＂。
㈥ 谁知道php使用sqlite3是用 new PDO 呢，，还是用 new SQLlite3 这个呢
两者都可以，都需要开启php的对应扩展。
用PDO可以使代码适用于多种数据库，使得代码抽象化，脱离数据库关联。
用指定SQLite3后，代码只能用于这种数据库。
尽量用PDO。
㈦ android手机上sqllite插入数据的性能是多少
SQLite 因其小巧轻便被安卓系统广泛采用，当然在操作小数据量时，差异并不明显；但当 SQLite 在操作略大一点的数据时就显得力不存心了，这时的 CRUD 操作对移动存储设备的性能有着极大的要求，另外用户体验的良好性也对 SQLite 的性能优化提出了要求。那么，当我们在操作大数据量时如何对 SQLite 进行优化呢？正确的操作是：开启事务。下面我们通过采用不同的方式向数据库中插入 10000 条数据来进行比较以体现开启事务对 SQLite 性能提升方面所做出的贡献。首先看一张截图来进行一个感性的认识：
源码及安装文件下载方式一：SQLiteDataBase.zip
从上图中我们会很清晰的看到通过普通方式插入 10000 条数据和开启事务插入 10000 条数据之间的差异，整整差了 83 秒。下面我们来看测试代码：
package cn.sunzn.sqlitedatabase;
import android.app.Activity;
import android.content.ContentValues;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.view.Menu;
import android.view.View;
import android.widget.EditText;
public class MainActivity extends Activity {
protected static final int SUCCESS_INSERT_TO_DB_ONE = 1;
protected static final int SUCCESS_INSERT_TO_DB_TWO = 2;
private EditText et_usedtime1;
private EditText et_usedtime2;
Handler handler = new Handler() {
public void handleMessage(Message msg) {
super.handleMessage(msg);
switch (msg.what) {
case SUCCESS_INSERT_TO_DB_ONE:
Integer usetime_one = (Integer) msg.obj;
et_usedtime1.setText("插入10000条数据耗时：" + usetime_one / 1000 + "秒");
break;
case SUCCESS_INSERT_TO_DB_TWO:
Integer usetime_two = (Integer) msg.obj;
et_usedtime2.setText("插入10000条数据耗时：" + usetime_two / 1000 + "秒");
break;
default:
break;
}
}
};
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
et_usedtime1 = (EditText) findViewById(R.id.et_usedtime1);
et_usedtime2 = (EditText) findViewById(R.id.et_usedtime2);
}
/**
* 1. 普通方式插入数据库 10000 条数据
*/
public void insert1(View view) {
MySQLiteOpenHelper openHelper = new MySQLiteOpenHelper(getApplicationContext());
final SQLiteDatabase database = openHelper.getWritableDatabase();
if (database.isOpen()) {
new Thread() {
public void run() {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000; i++) {
ContentValues values = new ContentValues();
values.put("name", "tom:" + i);
database.insert("person", "_id", values);
}
database.close();
long end = System.currentTimeMillis();
int usetime_one = (int) (end - start);
Message message = new Message();
message.what = SUCCESS_INSERT_TO_DB_ONE;
message.obj = usetime_one;
handler.sendMessage(message);
};
}.start();
}
}
/**
* 2. 开启事务插入数据库 10000 条数据
*/
public void insert2(View view) {
MySQLiteOpenHelper openHelper = new MySQLiteOpenHelper(getApplicationContext());
final SQLiteDatabase database = openHelper.getWritableDatabase();
if (database.isOpen()) {
new Thread() {
public void run() {
long start = System.currentTimeMillis();
database.beginTransaction();
for (int i = 0; i < 10000; i++) {
ContentValues values = new ContentValues();
values.put("name", "tom:" + i);
database.insert("person", "_id", values);
}
database.setTransactionSuccessful();
database.endTransaction();
database.close();
long end = System.currentTimeMillis();
int usetime_two = (int) (end - start);
Message message = new Message();
message.what = SUCCESS_INSERT_TO_DB_TWO;
message.obj = usetime_two;
handler.sendMessage(message);
};
}.start();
}
}
public boolean onCreateOptionsMenu(Menu menu) {
getMenuInflater().inflate(R.menu.activity_main, menu);
return true;
}
}
为什么只是开启了一个事务就会有这么大的差距呢？很简单，SQLite 缺省为每个操作开启了一个事务，那么测试代码循环插入 10000 次开启了 10000 个事务，"事务开启 + SQL 执行 + 事务关闭" 自然耗费了大量的时间，这也是后面显式开启事务后为什么如此快的原因。
㈧ php空间默认支持SQL Lite吗
SQL Lite不需要支不支持的,有WEB空间就能用.他只是文件式数据库.只要目录有读写权限就行.
㈨ sqllite究竟是个什么样的数据库
您好：
SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统，它包含在一个相对小的C库中。它的设计目标是嵌入式的，而且目前已经在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，比如 Tcl、C#、PHP、Java等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款开源的世界着名数据库管理系统来讲，它的处理速度比他们都快。
㈩ 如何修改MYSQL php配置文件 提高mysql性能
和php配置关系很少，还是在于数据结构的设置，mysql函数或者对象用完就释放删除，毕竟影响性能的问题还是在于sql语句的执行