應用場景：
長時間運行程序，需要幾乎整表查詢Mysql，還得在可容忍范圍內響應數據變化。
方案一：通過Mysql自帶的表更新時間
查詢方案：SELECT TABLE_NAME,UPDATE_TIME FROM INFORMATION_SCHEMA.tables WHERE TABLE_SCHEMA='Palas_V4';
存在問題：innodb 不支持，需要更換數據庫引擎；只支持表級判斷（可以接受）。
優點：查詢速度快。
變種解決方案：1、創建觸發器，在表執行update/insert/delete 時更新UPDATE_TIME為當前時間戳；2、在數據庫訪問接口處增加程序邏輯來更新該時間戳。
方案二：在所有行增加更新時間戳字段
查詢方案：判斷是否修改只需查詢該表最大的updatetime，增量更新僅需要查詢大於上次查詢時間的數據。
存在問題：表每行會增加4bytes的空間消耗，更新時間戳問題可通過mysql自身解決；不支持delete操作，如要刪除需要增加是否有效字段來改變狀態。
優點：可以做到行級的更新。
方案三：讀取Mysql文件的系統修改時間
查詢方案：獲取E:\SqlData\data\Palas_V4\ Media.frm 的系統修改時間
存在問題：需要在Mysql所在服務器操作，或者需要遠程訪問它的權限，可能導致安全問題；只支持表級判斷。
優點：速度快，不需要額外表空間或增加mysql負載。
變種解決方案：1、在Mysql所在服務器創建監控服務提供數據庫狀態信息。
方案選型：
優缺點分析：
方案一與二均需對數據庫做出相應修改，一所做修改對業務邏輯不會有影響，但對Mysql的操作會增加一倍（實際修改需要8（可能是4）個字節每次的數據量）無網絡傳輸；程序實現邏輯簡單；在數據修改量不大的情況話對性能幾乎沒有影響，但修改後查詢開銷大。方案二對表空間的增長會變大，對業務邏輯會有較小的影響(不再支持刪除)，部分表還需要增加字段判斷狀態，修改後查詢開銷較小。方案三性能與一相差不大，但需要額外編程提供狀態查詢，時間和硬盤IO會增大（不顯著）。
選型：
根據實際情況，排除暫時不會遇到的問題，優先級排列如下：
方案三 -> 方案二 –> 方案一 （方案一排最後是由於太多觸發器會導致表維護困難，更新引擎將使數據庫性能降低）
Mysql 開啟獨立表空間：
1. 停掉mysql： /etc/init.d/mysqld stop
2. 改my.cnf的配置文件： innodb-file-per-table=1
3. 備份使用innodb引擎的數據庫： mysqldump -u tg -p tg >/home/6fan/tg.sql;
4. 刪除使用innodb的數據庫，以及日志文件 。如果不刪除使用innodb的數據庫文件夾，啟動不了innodb引擎。
5. 啟動mysql ： /etc/init.d/mysqld start
6. 導入數據庫： mysql -u root -p < /home/6fan/tg.sql
有圖形化管理工具的在修改配置文件後直接備份需要監聽的數據庫，然後刪除後恢復也是可以的。
構建文件監聽與數據提供服務：
1、 在mysql服務器開啟文件監聽服務，提供get put方法（僅提供狀態，數據需要自己查）
2、 Get方法在全局數據提供服務啟動時調用，Put方法為主動向接受者聲明哪些需要同步
構建全局數據提供服務：(Web Api 支持json和xml格式)
1、 啟動時使用get獲取所有文件狀態；
2、 接受put的數據以啟用數據更新（可改為查詢時主動get）；
3、 有調用者時返回數據；
4、 對數據進行壓縮處理；保存以便傳輸
