㈠ 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語句的執行