本文目錄一覽：
通過分析比較主流數據庫技術，說出為什麼選擇mysql
通過分析比較主流數據庫技術，說出為什麼選擇mysql
MySQL是一種開放源代碼的關係型數據庫管理系統（RDBMS），MySQL數據庫系統使用最常用的數據庫管理語言–結構化查詢語言（SQL）進行數據庫管理
mysql 代理中間件能減輕數據庫壓力嗎
當使用MySQL數據庫的網站訪問量越來越大的時候，它的壓力也會越來越大，那麼如何給MySQL數據庫減壓呢？那就是優化！ 單機MySQL的優化有三種方法。分別是：一、服務器物理硬件的優化；二、MySQL安裝時的編譯優化；三、自身配置文件my.cnf的優化。一、服務器物理硬件的優化1、磁盤尋道能力(磁盤I/O) 是制約MySQL性能的最大因素之一，建議使用RAID1+0磁盤陣列，另外最好不要嘗試使用RAID-5，因為MySQL在RAID-5磁盤陣列上的效率實際上並不是很快;2、CPU也很重要，對於MySQL應用，推薦使用DELL R710，E5620 @2.40GHz(4 core)* 2或跟這個處理能力差不多的也行。 3、物理內存，物理內存對於一台使用MySQL的Database Server來說，服務器內存建議不要小於2GB，推薦使用4GB以上的物理內存。二、MySQL安裝時的編譯優化 建議採取編譯安裝的方法，這樣性能上有較大提升，服務器系統建議用64bit的Centos5.5，源碼包的編譯參數會默認以Debgu模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，所以當我們編譯準備安裝的產品代碼時，一定不要忘記使用“—without-debug”參數禁用Debug模式。 而如果把—with-mysqld-ldflags和—with-client-ldflags二個編譯參數設置為—all-static的話，可以告訴編譯器以靜態方式編譯和編譯結果代碼得到最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能差距可能會達到5%至10%之多。三、自身配置文件my.cnf的優化 當解決了上述服務器硬件制約因素後，讓我們看看MySQL自身的優化是如何操作的。對 MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面我們介紹一些對性能影響較大的參數。下面，我們根據以上硬件配置結合一份已經優化好的my.cnf進行說明：#vim /etc/my.cnf以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。[mysqld] port = 3306 serverid = 1 socket = /tmp/mysql.sockskip-locking#避免MySQL的外部鎖定，減少出錯幾率增強穩定性。skip-name-resolve#禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求!back_log = 384#back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。 如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自 己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。key_buffer_size = 384M#key_buffer_size指定用於索引的緩衝區大小，增加它可得到更好的索引處理性能。對於內存在4GB左右的服務器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是服務器整體效率降低!max_allowed_packet = 4M thread_stack = 256K table_cache = 614K sort_buffer_size = 6M#查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每連接獨佔，如果有100個連接，那麼實際分配的總共排序緩衝區大小為100 × 6 = 600MB。所以，對於內存在4GB左右的服務器推薦設置為6-8M。read_buffer_size = 4M#讀查詢操作所能使用的緩衝區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。join_buffer_size = 8M#聯合查詢操作所能使用的緩衝區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。myisam_sort_buffer_size = 64M table_cache = 512 thread_cache_size = 64 query_cache_size = 64M#指定MySQL查詢緩衝區的大小。可以通過在MySQL控制台觀察，如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩衝不夠 的情況;如果Qcache_hits的值非常大，則表明查詢緩衝使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩衝;Qcache_free_blocks，如果該值非常大，則表明緩衝區中碎片很多。tmp_table_size = 256M max_connections = 768#指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提 示，則需要增大該參數值。max_connect_errors = 1000 wait_timeout = 10#指定一個請求的最大連接時間，對於4GB左右內存的服務器可以設置為5-10。thread_concurrency = 8#該參數取值為服務器邏輯CPU數量*2，在本例中，服務器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4*2=8;這個目前也是雙四核主流服務器配置。skip-networking#開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB服務器是以遠程連接的方式訪問MySQL數據庫服務器則不要開啟該選項!否則將無法正常連接!table_cache=1024#物理內存越大,設置就越大.默認為2402,調到512-1024最佳innodb_additional_mem_pool_size=4M#默認為2Minnodb_flush_log_at_trx_commit=1#設置為0就是等到innodb_log_buffer_size列隊滿後再統一儲存,默認為1innodb_log_buffer_size=2M#默認為1Minnodb_thread_concurrency=8#你的服務器CPU有幾個就設置為幾,建議用默認一般為8key_buffer_size=256M#默認為218，調到128最佳tmp_table_size=64M#默認為16M，調到64-256最掛read_buffer_size=4M#默認為64Kread_rnd_buffer_size=16M#默認為256Ksort_buffer_size=32M#默認為256Kthread_cache_size=120#默認為60query_cache_size=32M 另外很多情況需要具體情況具體分析1、如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。2、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。 通過參數設置進行性能優化或多或少可以帶來性能的提升，但效果不一定會很突出。
連接數據庫mysql採用什麼技術
c#連接MySql數據庫的方法
一、用MySQLDriverCS連接MySQL數據庫。
先下載和安裝MySQLDriverCS，在安裝文件夾下面找到MySQLDriver.dll，然後將MySQLDriver.dll添加引用到項目中。
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using MySQLDriverCS;
namespace jxkh
{
public partial class frmLogin : Form
{
public frmLogin()
{
InitializeComponent();
}
private void btnLogin_Click(object sender, EventArgs e)
{
MySQLConnectionString tConnStr = new MySQLConnectionString(“10.14.55.46”, “performance”, “administrator”, “1234567@byd”, 3306);
MySQLConnection tConn = new MySQLConnection(tConnStr.AsString);
try
{
tConn.Open(); //打開連接
MySQLCommand cmd4 = new MySQLCommand(“set names gb2312”, tConn);
cmd4.ExecuteNonQuery();
string tCmd = “select ID,Name,PassWord from managers”; //命令語句
MySQLCommand cmd = new MySQLCommand(tCmd,tConn); //在定義的tConn對象上執行查詢命令
MySQLDataReader tReader = cmd.ExecuteReaderEx();
if(tReader.Read()) // 一次讀一條記錄
{
if(tReader[“Name”].ToString()==textBox1.TexttReader[“PassWord”].ToString()==textBox2.Text)
{
frmJxkh myJxkh = new frmJxkh();
myJxkh.Show();
}
}
tConn.Close();//重要！要及時關閉
tReader.Close();
}
catch
{
tConn.Close();
}
}
}
}
二、通過ODBC訪問mysql數據庫：
1. 安裝Microsoft ODBC.net；
2. 安裝MDAC 2.7或者更高版本；
3. 安裝MySQL的ODBC驅動程序；
4. 管理工具 – 數據源ODBC –配置DSN…；
5. 解決方案管理中添加引用 Microsoft.Data.Odbc.dll(1.0.3300)；
6. 代碼中增加引用 using Microsoft.Data.Odbc;
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Drawing;
using System.Linq; //vs2005好像沒有這個命名空間，在c#2008下測試自動生成的
using System.Text;
using System.Windows.Forms;
using Microsoft.Data.Odbc;
namespace mysql
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
string MyConString = “DRIVER={MySQL ODBC 3.51 Driver};” +
“SERVER=localhost;” +
“DATABASE=inv;” +
“UID=root;” +
“PASSWORD=831025;” +
“OPTION=3”;
OdbcConnection MyConnection = new OdbcConnection(MyConString);
MyConnection.Open();
Console.WriteLine(“”n success, connected successfully !”n”);
string query = “insert into test values( ‘hello’, ‘lucas’, ‘liu’)”;
OdbcCommand cmd = new OdbcCommand(query, MyConnection);
//處理異常：插入重複記錄有異常
try{
cmd.ExecuteNonQuery();
}
catch(Exception ex){
Console.WriteLine(“record duplicate.”);
}finally{
cmd.Dispose();
}
//***********************用read方法讀數據到textbox**********************
string tmp1 = null;
string tmp2 = null;
string tmp3 = null;
query = “select * from test “;
OdbcCommand cmd2 = new OdbcCommand(query, MyConnection);
OdbcDataReader reader = cmd2.ExecuteReader();
while (reader.Read())
{
tmp1 = reader[0].ToString();
tmp2 = reader[1].ToString();
tmp3 = reader[2].ToString();
}
this.textBox1.Text = tmp1 + ” ” + tmp2 + ” ” + tmp3;
*/
//************************用datagridview控件顯示數據表**************************
string MyConString = “DRIVER={MySQL ODBC 3.51 Driver};” +
“SERVER=localhost;” +
“DATABASE=inv;” +
“UID=root;” +
“PASSWORD=831025;” +
“OPTION=3”;
OdbcConnection MyConnection = new OdbcConnection(MyConString);
OdbcDataAdapter oda = new OdbcDataAdapter(“select * from customer “, MyConnection);
DataSet ds = new DataSet();
oda.Fill(ds, “employee”);
this.dataGridView1.DataSource = ds.Tables[“employee”];
*/
MyConnection.Close();
}
}
}
MySQL的sharding的程序是不是要自己開發的
不一定需要自己開發。Shard層可以位於：
1、DAO層：一般需要自行開發，可以靈活定製
2、ORM層：比如guzz、Hibernate Shard
3、JDBC API層：比較難，有一個商業產品dbShards
4、應用服務器與數據庫之間通過代理實現：MySQL Proxy、amoeba…..
一 背景
當數據庫中的數據量越來越大時，不論是讀還是寫，壓力都會變得越來越大。採用MySQL
Replication多master多slave方案，在上層做負載均衡，雖然能夠一定程度上緩解壓力。但是當一張表中的數據變得非常龐大時，壓力還是
非常大的。試想，如果一張表中的數據量達到了千萬甚至上億級別的時候，不管是建索引，優化緩存等，都會面臨巨大的性能壓力。
二 定義
數據sharding，也稱作數據切分，或分區。是指通過某種條件，把同一個數據庫中的數據分散到多個數據庫或多台機器上，以減小單台機器壓力。
三 分類
數據分區根據切分規則，可以分為兩類：
1、垂直切分
數據的垂直切分，也可以稱之為縱向切分。將數據庫想象成為由很多個一大塊一大塊的“數據塊”(表)組成，我們垂直的將這些“數據塊”切開，然後將他們分散
到多台數據庫主機上面。這樣的切分方法就是一個垂直(縱向)的數據切分。以表為單位，把不同的表分散到不同的數據庫或主機上。規則簡單，實施方便，適合業
務之間耦合度低的系統。
Sharding詳解” title=”MySQL Sharding詳解” height=”373″ width=”553″
垂直切分的優點
(1)數據庫的拆分簡單明了，拆分規則明確;
(2)應用程序模塊清晰明確，整合容易;
(3)數據維護方便易行，容易定位;
垂直切分的缺點
(1)部分表關聯無法在數據庫級別完成，需要在程序中完成;
(2)對於訪問極其頻繁且數據量超大的表仍然存在性能平靜，不一定能滿足要求;
(3)事務處理相對更為複雜;
(4) 切分達到一定程度之後，擴展性會遇到限制;
(5)過讀切分可能會帶來系統過渡複雜而難以維護。
2、水平切分
一般來說，簡單的水平切分主要是將某個訪問極其平凡的表再按照某個字段的某種規則來分散到多個表之中，每個表中包含一部分數據。以行為單位，將同一個表中的數據按照某種條件拆分到不同的數據庫或主機上。相對複雜，適合單表巨大的系統。
Sharding詳解” title=”MySQL Sharding詳解” height=”372″ width=”553″
水平切分的優點
(1)表關聯基本能夠在數據庫端全部完成;
(2)不會存在某些超大型數據量和高負載的表遇到瓶頸的問題;
(3)應用程序端整體架構改動相對較少;
(4)事務處理相對簡單;
(5)只要切分規則能夠定義好，基本上較難遇到擴展性限制;
水平切分的缺點
(1)切分規則相對更為複雜，很難抽象出一個能夠滿足整個數據庫的切分規則;
(2)後期數據的維護難度有所增加，人為手工定位數據更困難;
(3)應用系統各模塊耦合度較高，可能會對後面數據的遷移拆分造成一定的困難。
3、聯合切分
實際的應用場景中，除了那些負載並不是太大，業務邏輯也相對較簡單的系統可以通過上面兩種切分方法之一來解決擴展性問題之外，恐怕其他大部分業務邏輯稍微
複雜一點，系統負載大一些的系統，都無法通過上面任何一種數據的切分方法來實現較好的擴展性，而需要將上述兩種切分方法結合使用，不同的場景使用不同的切
分方法。
Sharding詳解” title=”MySQL Sharding詳解” height=”480″ width=”342″
聯合切分的優點
(1)可以充分利用垂直切分和水平切分各自的優勢而避免各自的缺陷;
(2)讓系統擴展性得到最大化提升;
聯合切分的缺點
(1)數據庫系統架構比較複雜，維護難度更大;
(2)應用程序架構也相對更複雜;
四 實現方案
現在 Sharding 相關的軟件實現其實不少，基於數據庫層、DAO 層、不同語言下也都不乏案例。限於篇幅，此處只作一下簡要的介紹。
1、 Mysql Proxy + HASCALE
一套比較有潛力的方案。其中MySQL Proxy 是用 Lua 腳本實現的，介於客戶端與服務器端之間，扮演 Proxy
的角色，提供查詢分析、失敗接管、查詢過濾、調整等功能。目前的 0.6 版本還做不到讀、寫分離。HSCALE 則是針對 MySQL Proxy 插件，也是用
Lua 實現的，對 Sharding 過程簡化了許多。需要指出的是，MySQL Proxy 與 HSCALE
各自會帶來一定的開銷，但這個開銷與集中式數據處理方式單條查詢的開銷還是要小的。
MySQLProxy是MySQL官方提供的一個數據庫代理層產品，和MySQLServer一樣，同樣是一個基於GPL開源協議的開源產品。可用來監視、分析或者傳輸他們之間的通訊信息。他的靈活性允許你最大限度的使用它，目前具備的功能主要有連接路由，Query分析，Query過濾和修改，負載均衡，以及基本的HA機制等。
實際上，MySQLProxy本身並不具有上述所有的這些功能，而是提供了實現上述功能的基礎。要實現這些功能，還需要通過我們自行編寫LUA腳本來實現。
MySQLProxy實際上是在客戶端請求與MySQLServer之間建立了一個連接池。所有客戶端請求都是發向MySQLProxy，然後經由MySQLProxy進行相應的分析，判斷出是讀操作還是寫操作，分發至對應的MySQLServer上。對於多節點Slave集群，也可以起做到負載均衡的效果。以下是MySQLProxy的基本架構圖：
Sharding詳解” title=”MySQL Sharding詳解” height=”480″ width=”420″
通過上面的架構簡圖，我們可以很清晰的看出MySQLProxy在實際應用中所處的位置，以及能做的基本事情。關於MySQLProxy更為詳細的實施細則在MySQL官方文檔中有非常詳細的介紹和示例，感興趣的讀者朋友可以直接從MySQL官方網站免費下載或者在線閱讀，我這裡就不累述浪費紙張了。
2、 Hibernate Shards
這是 Google 技術團隊貢獻的項目()，該項目是在對Google 財務系統數據
Sharding 過程中誕生的。因為是在框架層實現的，所以有其獨特的特性：標準的 Hibernate 編程模型，會用 Hibernate
就能搞定，技術成本較低;相對彈性的 Sharding 策略以及支持虛擬 Shard 等。
3、 Spock Proxy
這也是在實際需求中產生的一個開源項目，基於Mysql Proxy擴展。Spock()是一個人員查找的 Web
2.0 網站。通過對自己的單一 DB 進行有效 Sharding化 而產生了Spock
Proxy( ) 項目，Spock Proxy 算得上 MySQL Proxy
的一個分支，提供基於範圍的 Sharding 機制。Spock 是基於 Rails 的，所以Spock Proxy 也是基於 Rails 構建，關注 ROR
的朋友不應錯過這個項目。
4、 Amoeba for MySQL
Amoeba是一個基於Java開發的，專註於解決分布式數據庫數據源整合Proxy程序的開源框架，基於GPL3開源協議。目前，Amoeba已經具有Query路由，Query過濾，讀寫分離，負載均衡以及HA機制等相關內容。
Amoeba 主要解決的以下幾個問題：
(1)數據切分後複雜數據源整合;
(2)提供數據切分規則並降低數據切分規則給數據庫帶來的影響;
(3)降低數據庫與客戶端的連接數;
(4)讀寫分離路由。
我們可以看出，Amoeba所做的事情，正好就是我們通過數據切分來提升數據庫的擴展性所需要的。
Amoeba並不是一個代理層的Proxy程序，而是一個開發數據庫代理層Proxy程序的開發框架，目前基於Amoeba所開發的Proxy程序有AmoebaForMySQL和AmoebaForAladin兩個。
AmoebaForMySQL主要是專門針對MySQL數據庫的解決方案，前端應用程序請求的協議以及後端連接的數據源數據庫都必須是MySQL。對於客戶端的任何應用程序來說，AmoebaForMySQL和一個MySQL數據庫沒有什麼區別，任何使用MySQL協議的客戶端請求，都可以被AmoebaForMySQL解析並進行相應的處理。下如可以告訴我們AmoebaForMySQL的架構信息(出自Amoeba開發者博客)：
Sharding詳解” title=”MySQL Sharding詳解” height=”480″ width=”384″
AmoebaForAladin則是一個適用更為廣泛，功能更為強大的Proxy程序。他可以同時連接不同數據庫的數據源為前端應用程序提供服務，但是僅僅接受符合MySQL協議的客戶端應用程序請求。也就是說，只要前端應用程序通過MySQL協議連接上來之後，AmoebaForAladin會自動分析Query語句，根據Query語句中所請求的數據來自動識別出該所Query的數據源是在什麼類型數據庫的哪一個物理主機上面。下圖展示了AmoebaForAladin的架構細節(出自Amoeba開發者博客)：
Sharding詳解” title=”MySQL Sharding詳解” height=”480″ width=”384″
咋一看，兩者好像完全一樣嘛。細看之後，才會發現兩者主要的區別僅在於通過MySQLProtocalAdapter處理之後，根據分析結果判斷出數據源數據庫，然後選擇特定的JDBC驅動和相應協議連接後端數據庫。
其實通過上面兩個架構圖大家可能也已經發現了Amoeba的特點了，他僅僅只是一個開發框架，我們除了選擇他已經提供的ForMySQL和ForAladin這兩款產品之外，還可以基於自身的需求進行相應的二次開發，得到更適應我們自己應用特點的Proxy程序。
當對於使用MySQL數據庫來說，不論是AmoebaForMySQL還是AmoebaForAladin都可以很好的使用。當然，考慮到任何一個系統越是複雜，其性能肯定就會有一定的損失，維護成本自然也會相對更高一些。所以，對於僅僅需要使用MySQL數據庫的時候，我還是建議使用AmoebaForMySQL。
AmoebaForMySQL的使用非常簡單，所有的配置文件都是標準的XML文件，總共有四個配置文件。分別為：
(1)amoeba.xml：主配置文件，配置所有數據源以及Amoeba自身的參數設置;
(2)rule.xml：配置所有Query路由規則的信息;
(3)functionMap.xml：配置用於解析Query中的函數所對應的Java實現類;
(4)rullFunctionMap.xml：配置路由規則中需要使用到的特定函數的實現類;
如果您的規則不是太複雜，基本上僅需要使用到上面四個配置文件中的前面兩個就可完成所有工作。Proxy程序常用的功能如讀寫分離，負載均衡等配置都在amoeba.xml中進行。此外，Amoeba已經支持了實現數據的垂直切分和水平切分的自動路由，路由規則可以在rule.xml進行設置。
目前Amoeba少有欠缺的主要就是其在線管理功能以及對事務的支持了，曾經在與相關開發者的溝通過程中提出過相關的建議，希望能夠提供一個可以進行在線維護管理的命令行管理工具，方便在線維護使用，得到的反饋是管理專門的管理模塊已經納入開發日程了。另外在事務支持方面暫時還是Amoeba無法做到的，即使客戶端應用在提交給Amoeba的請求是包含事務信息的，Amoeba也會忽略事務相關信息。當然，在經過不斷完善之後，我相信事務支持肯定是Amoeba重點考慮增加的feature。
關於Amoeba更為詳細的使用方法讀者朋友可以通過Amoeba開發者博客()上面提供的使用手冊獲取，這裡就不再細述了。
案例()
操作文檔()
5、 HiveDB
和前面的MySQLProxy以及Amoeba一樣，HiveDB同樣是一個基於Java針對MySQL數據庫的提供數據切分及整合的開源框架，只是目前的HiveDB僅僅支持數據的水平切分。主要解決大數據量下數據庫的擴展性及數據的高性能訪問問題，同時支持數據的冗餘及基本的HA機制。
HiveDB的實現機制與MySQLProxy和Amoeba有一定的差異，他並不是藉助MySQL的Replication功能來實現數據的冗餘，而是自行實現了數據冗餘機制，而其底層主要是基於HibernateShards來實現的數據切分工作。
在HiveDB中，通過用戶自定義的各種Partitionkeys(其實就是制定數據切分規則)，將數據分散到多個MySQLServer中。在訪問的時候，在運行Query請求的時候，會自動分析過濾條件，並行從多個MySQLServer中讀取數據，併合並結果集返回給客戶端應用程序。
單純從功能方面來講，HiveDB可能並不如MySQLProxy和Amoeba那樣強大，但是其數據切分的思路與前面二者並無本質差異。此外，HiveDB並不僅僅只是一個開源愛好者所共享的內容，而是存在商業公司支持的開源項目。
下面是HiveDB官方網站上面一章圖片，描述了HiveDB如何來組織數據的基本信息，雖然不能詳細的表現出太多架構方面的信息，但是也基本可以展示出其在數據切分方面獨特的一面了。
Sharding詳解” title=”MySQL Sharding詳解” height=”471″ width=”553″
6、 DataFabric
application-level sharding
master/slave replication
7、PL/Proxy
前面幾個都是針對MySQL 的 Sharding 方案，PL/Proxy 則是針對 PostgreSQL 的，設計思想類似 Teradata 的
Hash 機制，數據存儲對客戶端是透明的，客戶請求發送到 PL/Proxy 後，由這裡分布式存儲過程調用，統一分發。 PL/Proxy
的設計初衷就是在這一層充當”數據總線”的職責，所以，當數據吞吐量支撐不住的時候，只需要增加更多的 PL/Proxy 服務器即可。大名鼎鼎的 Skype 用的就是
PL/Proxy 的解決方案。
8、Pyshards
這是個基於Python的解決方案。該工具的設計目標還有個 Re-balancing 在裡面，這倒是個比較激進的想法。目前只支持 MySQL
數據庫。
9、其他實現數據切分及整合的解決方案
除了上面介紹的幾個數據切分及整合的整體解決方案之外，還存在很多其他同樣提供了數據切分與整合的解決方案。如基於MySQLProxy的基礎上做了進一步擴展的HSCALE，通過Rails構建的SpockProxy，以及基於Pathon的Pyshards等等。
不管大家選擇使用哪一種解決方案，總體設計思路基本上都不應該會有任何變化，那就是通過數據的垂直和水平切分，增強數據庫的整體服務能力，讓應用系統的整體擴展能力儘可能的提升，擴展方式儘可能的便捷。
只要我們通過中間層Proxy應用程序較好的解決了數據切分和數據源整合問題，那麼數據庫的線性擴展能力將很容易做到像我們的應用程序一樣方便，只需要通過添加廉價的PCServer服務器，即可線性增加數據庫集群的整體服務能力，讓數據庫不再輕易成為應用系統的性能瓶頸。
五 注意事項
下面我們所說的分區，主要是指水平分區。
1、在實施分區前，我們可以查看所安裝版本的mysql是否支持分區：
mysql show variables like “%partition%”;
如果支持則會顯示：
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| have_partitioning | YES |
+——————-+——-+
2、分區適用於一個表的所有數據和索引，不能只對數據分區而不對索引分區，反之亦然，同時也不能只對錶的一部分進行分區。
3、分區類型
(1)RANGE 分區：基於屬於一個給定連續區間的列值，把多行分配給分區。
(2)LIST 分區：類似於按RANGE分區，區別在於LIST分區是基於列值匹配一個離散值集合中的某個值來進行選擇。
(3)HASH分區：基於用戶定義的表達式的返回值來進行選擇的分區，該表達式使用將要插入到表中的這些行的列值進行計算(新浪微博採用的方案)。
(4)KEY 分區：類似於按HASH分區，區別在於KEY分區只支持計算一列或多列，且MySQL
服務器提供其自身的哈希函數。必須有一列或多列包含整數值。
無論使用何種類型的分區，分區總是在創建時就自動的順序編號，且從0開始記錄。當有一新行插入到一個分區表中時，就是使用這些分區編號來識別正確的分區。
4、MySQL提供了許多修改分區表的方式。添加、刪除、重新定義、合併或拆分已經存在的分區是可能的。所有這些操作都可以通過使用ALTER TABLE
命令的分區擴展來實現。
5、可以對已經存在的表進行分區，直接使用alter table命令即可。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/227729.html
微信掃一掃 
支付寶掃一掃 