資料庫優化
1.在查詢欄位上建立索引
類似目錄，是對資料表中一列或多列的值進行排序的一種結構，方便快速查詢到資料
索引：普通索引、唯一索引、全文索引、btree索引、hash索引……
建立索引是資料庫優化各種方案之中成本最低，見效最快的解決方案，一般來講，資料庫規模在幾十萬和幾百萬級別的時候見效最快，即便是有不太複雜的表關聯，也能大幅度提高sql的執行效率，這個在我們以前的專案應用中，有非常深刻的體會，本來耗時50s的sql，在增加索引後可以提公升到1-2s，而且不需要有**改動，成本低廉，見效明顯
索引缺點：
第一，建立索引和維護索引要耗費時間，這種時間隨著資料量的增加而增加。
第二，索引需要佔物理空間，除了資料表佔資料空間之外，每乙個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。
第三，當對表中的資料進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了資料的維護速度。
2.分庫分表
分庫，可以按照業務分庫，分流資料庫併發壓力，使資料庫表更加有條理性，最起碼更加好找吧，我們當時是把查詢庫和系統庫(增刪改比較頻繁的表)分開了，這樣如果有大查詢，不影響系統庫
分表，剛才說了，索引適合應對百萬級別的資料量，千萬級別資料量使用的好，勉強也能湊合，但如果是上億級別的資料量，索引就無能為力了，因為單索引檔案可能就已經上百兆或者更多了，那麼，輪到我們的分表分割槽登場了
分表的方法有很多種
a、如果這個業務是有流程的，那麼我們通常會設計乙個歷史表或者歸檔表，用來存放歷史資料，這樣能保證實時資料效率比較高
b、針對某一張大表，可以根據查詢條件分成多張表，比如時間，我們可以將半個月或者10天的資料放到一張表裡(看具體資料量，個人認為3000w是個上限，最好控制到百萬級別)，每過10天，我們就自動建立一張資料庫表，然後將資料插入，如此，按照時間查詢，就要先定位去那種表中去取數，這樣，效率能夠得到大幅度提公升，當然，這麼解決也有問題，比如跨表，需要union多張表，而且跨表沒法支援索引
c、上面的方法是我們直接通過程式和資料庫實現的最原始的分表解決方案，現在市面上有一些成熟的軟體如mycat，也是支援分表的，我們之前從事的公司有個專門做分布式資料庫的，這些產品出現跨表，可以不使用程式union了，而且還是使索引生效，但是需要對產品有一定的掌握
d、一般來講，資料庫中的大表畢竟只是一少部分，僅需要對這少部分大表進行分表就可以了，沒必要小表也進行分表，增加維護開發難度
資料庫引擎
mysql比較常用的資料庫引擎有兩種，一種是innodb、一種是myisam
我當時做過乙個千萬級資料量複雜sql測試，myisam的效率大概能夠比innodb快1-2倍，雖然效率提公升不是很明顯，但是也有提公升，後來查過一些資料，說之所以mysiam快，是因為他的資料儲存結構、索引儲存結構和innodb不一樣的，mysiam的索引結構是在記憶體中存的
當然，mysiam也有弱點，那就是他是表級鎖，而innodb是行級鎖，所以，mysiam適用於一次插入，多次查詢的表，或者是讀寫分離中的讀庫中的表，而對於修改插入刪除操作比較頻繁的表，就很不合適了
資料庫優化 資料庫設計優化
一 索引優化 1.首先索引不是越多越好，要視情況而定。因為索引會降低insert和update的效率 insert和update有時可能會重建索引。2.乙個表的索參數量最好不要超過6個，擇優而建。3.專案上線後，根據使用者的查詢條件字段稍微調整資料庫中的字段索引。二 分表 1.縱切 根據表字段來且分...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...
資料庫優化
資料庫優化 1 合理使用索引 索引是資料庫中重要的資料結構，它的根本目的就是提高查詢效率。索引的使用要恰到好處，其使用原則如下 在經常進行連線，但是沒有指定為外來鍵的列上建立索引，而不經常連線的字段則由優化器自動生成索引 在頻繁進行排序或分組 即進行groupby或orderby操作 的列上建立索引...