模板
教程
環境
性能
功能
管理
性能優化篇：access的并發極限及超級分庫分散并發方案(十六)(2)
說明：
數了一下，有8個，常用的基本都是一個表一個數據庫，不常用的就還在一起一個數據庫。
其實，秋色園QBlog 的分庫，都是在寫這篇文章之前分的，也就是說，當初分庫的時候，我并不知道access的最大極限。
雖然我曾一度的百度及google過access的并發數或性能上限，但是，出來的網頁結果，都沒有我要的答案，于是我僅靠猜。
每次我見到秋色園QBlog打不開時，我都可以清楚的見到qblog.ldb文件，黃金4K的ldb文件，一開始我以為是4個并發鎖住了。
于是我也曾搜索去找到ldb的相關答案，可惜，仍找不到我要的答案，但是我知道黃金4K的ldb文件這個問題很嚴重。
于是，在秋色園QBlog 那個漫長的過程中，我是一步一步的分的庫，因為缺少真實的理解，我靠想象與猜測是某個表產生了死鎖引起的，因此我的第一理念，是把某個表分離出來。
因此，雖然現在你看到有8個庫，但這不是一次分出來的：
實際是某當qblog.mdb這個主庫遇到黃金4K最大鎖時，我就在懷疑某個表，然后就把某個表分出一個庫出來;
然后感覺又好了，再過不久，又出來黃金4K最大鎖，我又在懷疑是不是某表又鎖了，又分出了一個庫;
于是過了好長時間的如此如此般的重復，才最終形成這樣的分庫結果。
復制代碼
PS：在發布的CYQ.Blog(QBlog) V3.0 單用戶版本中，雖然發布的是一個數據庫，但是，隱藏著更高性能的分庫功能，即是說，如果想再提升性能，你還可以分庫，然后分一個庫補充1個鏈接即可。不過單用戶版本，V3.0的性能已經夠強悍了，而且同時還支持著多種數據庫。
分庫的功臣，Access鏈接表
在分庫的過程中，不得不提到Access的鏈接表，如果沒有它，分庫真的難以想象的復雜。
復雜在何處?當然是代碼的修改了，你能想象分布在兩個數據庫間的表鏈接查詢?
用鏈接表，代碼不用改，邏輯不用變，SQL語句仍照樣兼容，有點神奇。
分庫步驟(示例分庫用戶表Blog_User)：
1：新建一數據庫：qbloguser.mdb。
2：打開qbloguser.mdb，菜單：文件->獲取外部數據->導入，選擇qblog數據庫，將用戶表導進來，完成表的分庫轉移。
3：打開qblog.mdb，刪除用戶表，然后菜單：文件->獲取外部數據->鏈接表，從qbloguser.mdb中將用戶表鏈接過來。
復制代碼
OK，1分鐘內完成分庫并鏈接表，至此，并沒有代碼邏輯的修改，但是，僅是這樣的分庫，是無意義的。
因為并有沒散鏈接，操作用戶表時，還是操作的qblog.mdb數據庫，壓力并沒有分散。
代碼調整，分散單表操作的壓力
代碼還是需要調整，首先將表枚舉分出來：
public enum U_QBlogUserEnum
{
Blog_User,
}
因據 CYQ.Data 的多數據庫應用的約定，此表的數據庫鏈接將轉向配置項為QBlogUserConn項。
因此，僅需要多配置多一條數據庫鏈接指向qbloguser.mdb即完成了。
當然了，原來TableNames.Blog_User語句，批量替換成U_QBlogUserEnum.Blog_User就可以了。
再當然的話，代碼也不可能只改動這么小，因為，必須兼容一個庫的情況，比如CYQ.Blog(QBlog) V3.0發布時，
實際是支持分庫操作的，但是最終發布是一個庫發布的，因此，兼容的鏈接也必須處理。
再有一個提示，就是CYQ.Data 的ResetTable切換表操作功能，由于鏈接取的上一個，因此在分庫的情況下，每個表都是不同的鏈接，因此ResetTable的表操作，必須獨立出來操作。
復制代碼
強大的 CYQ.Data 數據框架(新提示：V4.0 以下版本免費且開源)，僅靠提取表枚舉頭部，就能自動切換數據庫，達到多數據庫應用。
于是，秋色園 QBlog 的Super分庫的策略，由此輕松的完成了。
最終形成的數據庫鏈接如下：
壓力分散是什么情況：
1：單表操作，分散到獨立的數據庫鏈接中，如qbloguser.mdb。
2：多表操作，直接操作的qblog.mdb的鏈接表。
3：每個庫都能同時支持64個并發鏈接。
復制代碼
總結
雖然秋色園 QBlog 整個的分庫策略，是長時間一步一步分的庫，由于原理是一致的，因此此文就一次性上齊了。
而且寫此文前進行的示例測試，有效的為自己和大伙解開access的并發上限之惑，
同時也解答了，多數庫分庫的確帶來并發上的好處。
然而分庫再怎么厲害，一個庫也是支持最大64個鏈接并發打開。
雖然：CYQ.Data 用Lock鎖住插入/更新/刪除，這些步驟，使的同一時間只出現一個鏈接打開。
但是，通過今天的示例，發現了，讀取，也是要打開鏈接的。
因此，優化并沒有止步，本系列還在繼續，請繼續關注。
復制代碼
