trx部署

1. iost幣是主鏈還是測

主鏈，IOST已正式成為ETH、EOS、TRX外全球Top 4的DApp公鏈平台，IOST主網日交易數也已超過以太坊，位列全球第三。未來，IOST要打造全球第一個擴容基礎上去中心化的區塊鏈項目，一起搭建全世界最大的去中心化體系。

2. trx轉賬需要多少能量

轉賬1個TRR代幣大概需要315能量。

轉賬TRC20代幣或交易等，都會消耗能量和帶寬。比如以轉賬TRR代幣為例：轉賬89個TRR代幣需要消耗345帶寬和28031能量，該地址沒有足夠的能量，則抵扣了3.92434TRX作為手續費。

眾所周知，波場代幣主要分為TRC10和TRC20代幣，資源主要分為三種：能量、帶寬和存儲。在波場獨特的網路中，存儲幾乎是無限的。那麼能量和帶寬是有限的，用完了就需要花TRX來租賃或者凍結獲得能量和帶寬。

RC10代幣是一種是通過TRON公鏈內置的通證。主要消耗帶寬。

TRC20代幣是在TRON區塊鏈上通過部署智能合約的方式來發行資產的一套標准，主要消耗能量和帶寬。

每個波場賬戶每天擁有1500帶寬，用完會自動慢慢恢復至1500.目前轉賬TRC10代幣一筆大概需要消耗300-400帶寬，即每個賬戶每天可以免費轉3-4筆TRC10代幣，比如TRX。如果當日轉賬次數過多，沒有足夠的帶寬來消耗，就會直接抵扣賬戶上面的TRX估為手續費。

能量是比較「珍貴」的資源了，賬戶每天沒有免費的能量，如果想要獲得能量有2種方式可以獲得：

1、凍結TRX獲得能量。TRON網路中凍結1萬TRX，可以獲得257431能量。

2、租賃。通過波場助手tronenergy.app能量平台，用1TRX可以租賃10800能量。

3. cas單點登錄配置，伺服器超時刷新頁面報錯

首先回答你第一個問題，安全證書是tomcat或者apache用於開啟ssl安全的socket鏈接使用的，也就是支持https協議的。一般我們都用tomcat作為應用伺服器，這樣就需要tomcat首先支持https協議，開啟https很簡單，找一下官方的文檔資料，我在這里簡單說一下，首先在部署tomcat的機器上為jdk（確切的說是jre，不過通常我們都在tomcat的伺服器上安裝jdk而不是jre）生成證書，使用jre自帶的keytool工具來生成即可，生成證書的過程中注意一點，就是CN項，也就是第一個欄位，是伺服器的域名，比如本機測試的話可以用localhost。使用以下語句
1. keytool -keystore keystore -alias acegisecurity -genkey -keyalg RSA -validity 9999 -storepass password -keypass password
What is your first and last name?（這個就是CN項）回答localhost即可
其他隨便填寫即可。
2. keytool -export -v -rfc -alias acegisecurity -file acegisecurity.txt -keystore keystore -storepass password
這一步是導出key。
3. 復制 acegisecurity.txt 到 %JAVA_HOME%\jre\lib\security  

4. 復制 keystore 到 %CATALINA_HOME %
5. 控制台窗口（如果是Windows系統就是dos窗口）下進入 %JAVA_HOME%\jre\lib\security
6. keytool -import -v -file acegisecurity.txt -keypass password - keystore cacerts -storepass changeit -alias acegisecurity
向虛擬機中導入證書
接下來，用編輯器打開%CATALINA_HOME%/conf/server.xml，找到<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
這一行默認是被注釋掉的，取消注釋，並加入keystoreFile="keystore" keystorePass="password"這兩個屬性，注意keystoreFile屬性可以使用keystore文件的絕對路徑，也可使用基於%CATALINA_HOME%環境變數的相對路徑，keystorePass是訪問keystore的密碼，應和上面製作證書時設定的密碼保持一致。
訪問https://localhost:8443，應彈出一個對話框，告知用戶正要訪問的站點的證書不安全，是否接受，確認接受，應可看到那隻熟悉可愛的小貓。
通過以上步驟就為tomcat配置了ssl。

配置了ssl，然後就是把cas server的war部署到這個tomcat下就可以了，到此，你的cas伺服器就算部署成功了，但是，cas server那個war默認是使用user.properties中的那麼幾個用戶做認證，要實現不同類型的認證方式還需要自己開發，這里不具體講了，可以參考官方文檔，也可以問我。呵呵：）

部署了cas服務，接下來就是接入client application了。
接入application有三種方式，一種是使用acegisecurity，很好用，但是很復雜；一種是使用cas提供的cas client，簡單快捷，適應各種惡劣環境，哈哈；最後一種是lam的一個開源項目，沒試過，不敢說怎麼樣。前兩種不明白可以找官方文檔，也尅問我，哈哈。
就第一個問題說的較詳細，實在打字太多，有點累了。後面的有點粗糙，不過對於有心的人我相信還是很受用的。總結了很久的東西，希望對你有幫助。

4. MySQL 5.7中新增sys schema有什麼好處

性能優化利器:剖析MySQL 5.7新特徵 sys schema

導讀：很多團隊在評估合適的時機切換到 MySQL 5.7，本文是在高可用架構群的分享，介紹 MySQL 5.7 新的性能分析利器。

李春，現任科技 MySQL 負責人，高級 MySQL 資料庫專家，從事 MySQL 開發和運維工作 8 年。在擔任 MySQL 資料庫 leader 期間，主要負責應用架構的優化和部署，實現了阿里巴巴 3 億 產品 從 Oracle 小型機到 64 台 MySQL 的平滑遷移。專注於研究 MySQL 復制、高可用、分布式和運維自動化相關領域。在大規模、分布式 MySQL 集群管理、調優、快速定位和解決問題方面有豐富經驗。管理超過 1400 台 MySQL 伺服器，近 3000 個實例。完成 MySQL 自動裝機系統、MySQL 標准化文檔和操作手冊、MySQL 自動規范性檢查系統、MySQL 自動信息採集系統等標准化文檔和自動化運維工具。

sys schema 由來

Performance schema 引入

Oracle 早就有了 v$ 等一系列方便診斷資料庫性能的工具，MySQL DBA 只有羨慕嫉妒恨的份，但是 5.7 引入的 sys schema 緩解了這個問題，讓我們可以通過 sys schema 一窺 MySQL 性能損耗，診斷 MySQL 的各種問題。

說到診斷 MySQL 性能問題，不得不提在 MySQL 5.5 引入的 performance_schema，最開始引入時，MySQL 的 performance_schema 性能消耗巨大，隨著版本的更新和代碼優化，5.7 的 performance_schema 對 MySQL 伺服器額外的消耗越來越少，我們可以放心的打開 performance_shema 來收集 MySQL 資料庫的性能損耗。Tarique Saleem 同學測試了一下 sys schema 對 CPU 和 IO的額外消耗，基本在 1% - 3% 之間，有興趣的同學可以參考他的這篇 blog：

（CPU Bound, Sysbench Read Only Mode）

performance_schema 不僅由於他的性能消耗大著名，還由於其復雜難用而臭名昭著。5.7 上的 performance schema 已經有 87 張表了，每個表都是各種統計信息的羅列；另外，他的這些表和 information_schema 中的部分表也纏夾不清，讓大家用得很不習慣。

sys schema VS performance schema VS information schema

現在 MySQL 在 5.7 又新增了sys schema，它和 performance_schema 和 information schema 到底是什麼關系？

Information_schema 定位基本是 MySQL 元數據信息，比如：TABLES 記錄了 MySQL 有哪些表，COLUMNS 記錄了各個表有哪些列 。

performance_schema 記錄了 MySQL 實時底層性能消耗情況，比如：events_waits_current 記錄了 MySQL 各個線程當前在等待的 event。

雖然他們之間的這個定位區別並沒有那麼明顯：比如，Information_schema 的 innodb_locks 就記錄了 innodb 當前鎖的信息，它並不是 MySQL 的元數據信息。sys schema 最開始是 MarkLeith 同學為了方便讀取和診斷 MySQL 性能引入到 MySQL 的。所以 sys schema 定位應該是最清晰的：它包含一系列對象，這些對象能夠輔助 DBA 和開發人員了解 performance schema 和 information_schema 採集的數據。

sys schema 包含了什麼？

sys schema 包含一些對象，這些對象主要用於調優和故障分析。包括：

將 performance schema 和 information schema 中的數據用更容易理解的方式來總結歸納出來的「視圖」。

提供 performance schema 和 information schema 配置或者生成分析報告類似操作的「存儲過程」

sys schema 本身不採集和存儲什麼信息，它只是為程序或者用戶提供一個更加方便的診斷系統性能和排除故障的「介面」。也就是說，查詢 performance schema 和 information schema 配置和提供格式化服務的「存儲函數」。

避免用戶在 information schema 和 performance schema 中寫各種復雜的查詢來獲得到底誰鎖了誰，每個線程消耗的內存是多少 ( 視圖 memory_by_thread_by_current_bytes )，每個 SQL 執行了多少次，大致的執行時間是多少（ 視圖 statements_with_runtimes_in_95th_percentile ）等，這些 sys schema 都直接幫你寫好，你只需要直接查詢就好了。

編寫了一些現成的存儲過程，方便你：直接使用 diagnostics() 存儲過程創建用於診斷當前伺服器狀態的報告；使用 ps_trace_thread() 存儲過程創建對應線程的圖形化（ .dot類型 ）性能數據。

編寫了一些現成的存儲函數，方便你：直接使用 ps_thread_account() 存儲函數獲得發起這個線程的用戶，使用 ps_thread_trx_info() 來獲得某線程當前事務或者歷史執行過的語句（ JSON 格式返回 ）。

當然，你也可以在 sys schema 下增加自己用於診斷 MySQL 性能的「視圖」、「存儲過程」和「存儲函數」。

sys schema 舉例

怎麼利用 sys schema 來定位問題和診斷資料庫性能？這里簡單舉一個 innodb 行鎖的例子來說明。

模擬行鎖

拿一個實際的場景來說 sys schema 能夠輔助我們分析當前資料庫上哪個 session 被鎖住了，並且提供「清理」鎖的語句。我們模擬一個表的某一行被鎖住的情況，假設表創建語句如下：

CREATE TABLE `test2` (

`id` int(11) NOT NULL,

`name` varchar(16) DEFAULT NULL,

`age` int(11) DEFAULT NULL,

`sex` int(11) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

有一條數據如下：

mysql > select * from test2;

+----+---------+------+------+

| id | name | age | sex |

+----+---------+------+------+

| 2 | pickup1 | 1 | 1 |

+----+---------+------+------+

我們分別在 session 1 和 session 2 上同時操作這條數據，這樣的話必然對同一行記錄相互有鎖死的情況，然後我們通過 session 3 來查看 sys schema 裡面的 innodb_lock_waits，確定到底是誰鎖了誰，怎麼解鎖？操作步驟如下：

通過 sys.innodb_lock_waits 查看 innodb 鎖表情況

對應的在 session 3上查看到的記錄：

mysql > select * from sys.innodb_lock_waitsG

*************************** 1. row ***************************

wait_started: 2016-05-04 01:04:38

wait_age: 00:00:02

wait_age_secs: 2

locked_table: `test`.`test2`

locked_index: PRIMARY

locked_type: RECORD

waiting_trx_id: 5382

waiting_trx_started: 2016-05-04 00:24:21

waiting_trx_age: 00:40:19

waiting_trx_rows_locked: 4

waiting_trx_rows_modified: 0

waiting_pid: 3

waiting_query: update test2 set name='pickup3' where id=2

waiting_lock_id: 5382:31:3:3

waiting_lock_mode: X

blocking_trx_id: 5381

blocking_pid: 2

blocking_query: NULL

blocking_lock_id: 5381:31:3:3

blocking_lock_mode: X

blocking_trx_started: 2016-05-04 00:23:49

blocking_trx_age: 00:40:51

blocking_trx_rows_locked: 1

blocking_trx_rows_modified: 1

sql_kill_blocking_query: KILL QUERY 2

sql_kill_blocking_connection: KILL 2

這里我們可以看到 3 號線程（ waiting_pid: 3 ）在等待 2 號線程（ blocking_pid: 2 ）的 X 鎖（ blocking_lock_mode: X ），如果需要解鎖，需要殺掉 2 號線程（ sql_kill_blocking_connection: KILL 2 ）。

innodb_lock_waits 本質

其實 sys schema 的 innodb_lock_waits 只是 information schema 的視圖而已。

CREATE ALGORITHM = TEMPTABLE DEFINER = `mysql.sys`@`localhost` SQL SECURITY INVOKER VIEW `innodb_lock_waits` AS

SELECT

`r`.`trx_wait_started` AS `wait_started`,

TIMEDIFF(NOW(),

`r`.`trx_wait_started`) AS `wait_age`,

TIMESTAMPDIFF(

SECOND,

`r`.`trx_wait_started`,

NOW()) AS `wait_age_secs`,

`rl`.`lock_table` AS `locked_table`,

`rl`.`lock_index` AS `locked_index`,

`rl`.`lock_type` AS `locked_type`,

`r`.`trx_id` AS `waiting_trx_id`,

`r`.`trx_started` AS `waiting_trx_started`,

TIMEDIFF(NOW(),

`r`.`trx_started`) AS `waiting_trx_age`,

`r`.`trx_rows_locked` AS `waiting_trx_rows_locked`,

`r`.`trx_rows_modified` AS `waiting_trx_rows_modified`,

`r`.`trx_mysql_thread_id` AS `waiting_pid`,

`sys`.`format_statement`(`r`.`trx_query`) AS `waiting_query`,

`rl`.`lock_id` AS `waiting_lock_id`,

`rl`.`lock_mode` AS `waiting_lock_mode`,

`b`.`trx_id` AS `blocking_trx_id`,

`b`.`trx_mysql_thread_id` AS `blocking_pid`,

`sys`.`format_statement`(`b`.`trx_query`) AS `blocking_query`,

`bl`.`lock_id` AS `blocking_lock_id`,

`bl`.`lock_mode` AS `blocking_lock_mode`,

`b`.`trx_started` AS `blocking_trx_started`,

TIMEDIFF(NOW(),

`b`.`trx_started`) AS `blocking_trx_age`,

`b`.`trx_rows_locked` AS `blocking_trx_rows_locked`,

`b`.`trx_rows_modified` AS `blocking_trx_rows_modified`,

CONCAT(

'KILL QUERY ',

`b`.`trx_mysql_thread_id`

) AS `sql_kill_blocking_query`,

CONCAT('KILL ',

`b`.`trx_mysql_thread_id`) AS `sql_kill_blocking_connection`

FROM

(

(

(

(

`information_schema`.`innodb_lock_waits` `w`

JOIN

`information_schema`.`innodb_trx` `b` ON((`b`.`trx_id` = `w`.`blocking_trx_id`))

)

JOIN

`information_schema`.`innodb_trx` `r` ON(

(`r`.`trx_id` = `w`.`requesting_trx_id`)

)

)

JOIN

`information_schema`.`innodb_locks` `bl` ON(

(

`bl`.`lock_id` = `w`.`blocking_lock_id`

)

)

)

JOIN

`information_schema`.`innodb_locks` `rl` ON(

(

`rl`.`lock_id` = `w`.`requested_lock_id`

)

)

)

ORDER BY

`r`.`trx_wait_started`

innodb_lock_waits和x$innodb_lock_waits區別

有心的同學可能會注意到，sys schema 裡面有 innodb_lock_waits 和 x$innodb_lock_waits。其實 sys schema 的這些視圖大部分都成對出現，其中一個的名字除了 x$ 前綴以外跟另外一個是一模一樣的。例如，host_summmary_by_file_io 視圖分析匯總的是根據主機匯總的文件 IO 情況，並將延遲從皮秒（ picoseconds ）轉換成更加易讀值（ 帶單位 ）顯示出來：

mysql> SELECT * FROM host_summary_by_file_io;

+------------+-------+------------+

| host | ios | io_latency |

+------------+-------+------------+

| localhost | 67570 | 5.38 s |

| background | 3468 | 4.18 s |

+------------+-------+------------+

而 x$host_summary_by_file_io 視圖分析匯總的是同樣的數據，但是顯示的是未格式化過的皮秒（ picosecond ）延遲值

mysql> SELECT * FROM x$host_summary_by_file_io;

+------------+-------+---------------+

| host | ios | io_latency |

+------------+-------+---------------+

| localhost | 67574 | 5380678125144 |

| background | 3474 | 4758696829416 |

+------------+-------+---------------+

沒有 x$ 前綴的視圖是為了提供更加友好，對人更加易讀的輸出格式。帶 x$ 前綴的視圖顯示了數據原始格式，它方便其他工具基於這些數據進行自己的處理。需要了解非 x$ 和 x$ 視圖的不同點的進一步信息。

Q&A

提問：sys schema 只是在 performance_schema 和 information_schema 之上創建視圖和存儲過程？

李春：對，sys schema 主要針對的其實是 iperformance schema，有部分 information schema 的表也會整理到 sys schema 中統一展現。

提問：運行 KILL 2 殺掉 2 線程？blocking_lock_mode: X 的 X 什麼意思？

李春：blocking_lock_mode 的 X 是指 X 鎖，exclusive 鎖，排它鎖，跟它對應的是 S 鎖，共享鎖。kill 2 是殺掉 2 號線程，這樣可以將鎖釋放，讓被鎖的這個線程正常執行下去。

提問：可以放心的打開 performance_schema，為何不使用 performance_schema 再造一個 sys schema？

李春：performance schema 是 MySQL 採集資料庫性能的存儲空間。sys schema 其實只是對 performance schema 多個表 join 和整合。兩者的定位有所不同，如果直接放在 performance schema 中，分不清哪些是基表，哪些是視圖，會比較混淆。

提問：pt-query-digest 這些工具的有開始使用 sys schema 嗎？

李春：沒有，pt-query-digest 主要用於分析慢查和 tcpmp 的結果，跟 sys schema 的定位有部分重疊的地方，sys schema 會分析得更細，更內核，更偏底層一些，pt-query-digest 主要還是從慢查和 tcpmp 中抽取 SQL 來格式化展現。

提問：阿里這么多資料庫實例，使用什麼運維工具？分布式事務又是怎麼解決的呢？

李春：阿里內部有非常多的運維工具，dbfree，idb 等，用於資料庫資源池管理，資料庫脫敏，開發測試庫同步，資料庫訂正，表結構變更等。分布式事務主要通過業務上的修改去屏蔽掉，比如：電影買票並不是你選了座位和付款就必須在一個事務裡面，搶票，選座，付款分別是自己的子事務，系統耦合性比較弱，相互通知解決問題。

提問：Oracle 有 v$，MySQL 有 x$ ？兩個 $ 是完成相似功能的嗎？

李春：MySQL 的 x$ 可以說是仿照 Oracle 的 v$ 來做的，但是目前離 Oracle 的那麼強大的資料庫診斷功能還有一些距離。

提問：資料庫脫敏能否簡單介紹下實現方式？

李春：開發測試人員無法訪問線上資料庫，需要通過一個專門的 idb 來訪問，而 idb 系統每個欄位都有密級定義，滿足許可權的才能被訪問；這個系統頁控制了用戶是否可以訪問某個表，可以訪問數據表的行數，只有主管同意了，用戶才能訪問某個表的數據，並且加密數據是以*顯示的。

5. 如何優化mysql寫入速

單機MySQL資料庫的優化
一、伺服器硬體對MySQL性能的影響
①磁碟尋道能力 （磁碟I/O），我們現在上的都是SAS15000轉的硬碟。MySQL每秒鍾都在進行大量、復雜的查詢操作，對磁碟的讀寫量可想而知。所以，通常認為磁 盤I/O是制約MySQL性能的最大因素之一，對於日均訪 問量在100萬PV以上的Discuz!論壇，由於磁碟I/O的制約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案： 使用RAID1+0磁碟陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁碟陣列上的效率不會像你期待的那樣快。
②CPU 對於MySQL應用，推薦使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我現在比較喜歡DELL R710，也在用其作Linuxakg 虛擬化應用；
③物理內存對於一台使用MySQL的Database Server來說，伺服器內存建議不要小於2GB，推薦使用4GB以上的物理內存，不過內存對於現在的伺服器而言可以說是一個可以忽略的問題，工作中遇到高端伺服器基本上內存都超過了32G。
我們工作中用得比較多的資料庫伺服器是HP DL580G5和DELL R710，穩定性和性能都不錯；特別是DELL R710，我發現許多同行都是採用它作資料庫的伺服器，所以重點推薦下。
二、MySQL的線上安裝我建議採取編譯安裝的方法，這樣性能上有較大提升，伺服器系統我建議用64bit的Centos5.5，源碼包的編譯參數會默 認以Debgu模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，所以當我們編譯准備安裝的產品代碼時，一定不要忘記使用「— without-debug」參數禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二 個編譯參數設置為—all-static的話，可以告訴編譯器以靜態方式編譯和編譯結果代碼得到最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能 差距可能會達到5%至10%之多。我參考了簡朝陽先生的編譯參數，特列如下，供大家參考
./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎麼了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素當解決了上述伺服器硬體制約因素後，讓我們看看MySQL自身的優化是如何操作的。對 MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。
下面，根據以上硬體配置結合一份已經優化好的my.cnf進行說明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-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
#默認為2M
innodb_flush_log_at_trx_commit=1
#設置為0就是等到innodb_log_buffer_size列隊滿後再統一儲存，默認為1
innodb_log_buffer_size=2M
#默認為1M
innodb_thread_concurrency=8
#你的伺服器CPU有幾個就設置為幾，建議用默認一般為8
key_buffer_size=256M
#默認為218，調到128最佳
tmp_table_size=64M
#默認為16M，調到64-256最掛
read_buffer_size=4M
#默認為64K
read_rnd_buffer_size=16M
#默認為256K
sort_buffer_size=32M
#默認為256K
thread_cache_size=120
#默認為60
query_cache_size=32M
※值得注意的是：
很多情況需要具體情況具體分析
一、如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。
很多時候我們發現，通過參數設置進行性能優化所帶來的性能提升，可能並不如許多人想像的那樣產生質的飛躍，除非是之前的設置存在嚴重不合理的情況。我們 不能將性能調優完全依託於通過DBA在資料庫上線後進行的參數調整，而應該在系統設計和開發階段就盡可能減少性能問題。
【51CTO獨家特稿】如果單MySQL的優化始終還是頂不住壓力時，這個時候我們就必須考慮MySQL的高可用架構（很多同學也愛說成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
優勢：可用性非常高，性能非常好。每份數據至少可在不同主機存一份拷貝，且冗餘數據拷貝實時同步。但它的維護非常復雜，存在部分Bug，目前還不適合比較核心的線上系統，所以這個我不推薦。
二、DRBD磁碟網路鏡像方案
優勢：軟體功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足資料庫對數據一致 性的苛刻要求。但非分布式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於 MySQL Replication。另外，DRBD也是官方推薦的可用於MySQL高可用方案之一，所以這個大家可根據實際環境來考慮是否部署。
三、MySQL Replication
在實際應用場景中，MySQL Replication是使用最為廣泛的一種提高系統擴展性的設計手段。眾多的MySQL使用者通過Replication功能提升系統的擴展性後，通過 簡單的增加價格低廉的硬體設備成倍 甚至成數量級地提高了原有系統的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。
比較常規的MySQL Replication架構也有好幾種，這里分別簡單說明下
MySQL Replication架構一：常規復制架構--Master-slaves，是由一個Master復制到一個或多個Salve的架構模式，主要用於讀壓力大的應用資料庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。
MySQL Replication架構二：級聯復制架構，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。
MySQL Replication架構三：Dual Master與級聯復制結合架構，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的復制帶來的影響，而且保證了主Master的單點故障。
以上就是比較常見的MySQL replication架構方案，大家可根據自己公司的具體環境來設計 ，Mysql 負載均衡可考慮用LVS或Haproxy來做，高可用HA軟體我推薦Heartbeat。
MySQL Replication的不足：如果Master主機硬體故障無法恢復，則可能造成部分未傳送到slave端的數據丟失。所以大家應該根據自己目前的網路 規劃，選擇自己合理的Mysql架構方案，跟自己的MySQL DBA和程序員多溝涌，多備份（備份我至少會做到本地和異地雙備份），多測試，數據的事是最大的事，出不得半點差錯，切記切記。

6. 如何：配置測試部署

如果將測試部署到單獨的文件夾中，則在運行測試時可以繼續生成解決方案。在測試運行之前，以下文件和文件夾將復制到部署文件夾中：測試程序集文件所有依賴程序集已指定的測試所依賴文件，例如 XML 文件和配置文件。可以用兩種方式來配置部署：一種是指定要復制的其他部署項，一種是更改相應的部署文件夾。部署文件夾可以是本地文件夾，也可以是遠程文件夾。當您使用測試代理控制器和測試代理時，將發生遠程測試部署。有關遠程部署的更多信息，請參見如何：使用測試控制器和測試代理運行測試。在運行解決方案的測試時，Visual Studio 會在解決方案層次結構中名為 TestResults 的文件夾下創建部署文件。如果TestResults 文件夾不存在，Visual Studio 會創建它。注意如果使用 Visual Studio IDE，此文件夾便會直接創建在解決方案文件夾之下；如果沒有使用 Visual Studio IDE，TestResults 文件夾便會創建在當前文件夾之下。每次開始測試運行時，Visual Studio 都會在 TestResults 文件夾下創建一組專供此次測試運行使用的文件夾。在下圖所示的示例中，TestResults 下的第一個文件夾是「@ 」。這是用於命名每個測試運行文件夾的模式。本地測試運行的部署文件夾正如上圖中所示，解決方案 ClassLibrary1 中包含兩個項目：ClassLibary1 和 TestProject1。由於測試已經運行，所以此解決方案中還包含一個名為 TestResults 的文件夾。對於每個測試運行，TestResults 文件夾中都包含一個對應的測試結果文件。此測試結果文件帶有 .trx 擴展名。TestResults 文件夾下還將創建一些其他的文件夾，如下所述：測試運行文件夾。在TestResults 文件夾下，為已啟動的每個測試運行都建立了一個文件夾。正如「測試結果」窗口和「測試運行」窗口中所顯示的，測試運行文件夾與測試運行同名。測試運行名稱的默認格式為 @ 。測試運行文件夾中還包含在測試運行前後運行的清理腳本。Out 文件夾和子文件夾。每個測試運行文件夾都包含一個名為 Out 的文件夾。Out 文件夾是實際部署文件夾。每次啟動測試運行時，都要將測試運行所需的程序集及其他文件或文件夾復制到 \TestResults\\Out 文件夾中。In 文件夾和子文件夾。每個測試運行文件夾都包含一個名為 In 的文件夾。當生成某些測試結果時，會將這些結果存儲在 In 文件夾或一個子文件中。例如，代碼覆蓋率結果將存儲在一個名為 data.coverage 的文件中，而該文件位於名為 \ 的子文件夾中。設置部署選項可以通過以下方式控制測試部署：啟用或禁用部署。您可以選擇是在部署文件夾中運行測試，還是就地運行測試。有關執行此操作的過程步驟，請參見創建測試設置以從 Visual Studio 中運行自動測試或創建作為測試計劃一部分的自動測試的測試設置。選擇部署項。對於本地測試部署，測試引擎在運行測試之前將部署項（包括文件和文件夾）復制到您計算機上的某個文件夾中。可以在測試設置文件中添加要部署的文件和文件夾。有關執行此操作的步驟，請參見創建測試設置以從 Visual Studio 中運行自動測試或創建作為測試計劃一部分的自動測試的測試設置。有關復制部署項的順序的信息，請參見部署順序。

7. 如何利用腳本實現MySQL的快速部署以及一機多實例的部署

給你個linux的配置my.cnf的內容[mysqld_multi]mysqld=/usr/local/mysql/bin/mysqld_safe[client]socket=/tmp/mysql.sockdefault-character-set=utf8[mysqld1]datadir=/usr/local/mysql/databasedir=/usr/local/mysqlcharacter-set-server=utf8default-storage-engine=innodbport=3306table_open_cache=64innodb_data_home_dir=/usr/local/mysql/datainnodb_data_file_path=ibdata1:10M:autoextendinnodb_log_group_home_dir=/usr/local/mysql/datainnodb_buffer_pool_size=50Minnodb_additional_mem_pool_size=2Minnodb_log_file_size=5Minnodb_log_buffer_size=8Minnodb_flush_log_at_trx_commit=1innodb_lock_wait_timeout=50[mysqld2]datadir=/usr/local/mysql/data1basedir=/usr/local/mysqlcharacter-set-server=utf8default-storage-engine=innodbport=3307table_open_cache=64innodb_data_home_dir=/usr/local/mysql/data1innodb_data_file_path=ibdata1:10M:autoextendinnodb_log_group_home_dir=/usr/local/mysql/data1innodb_buffer_pool_size=50Minnodb_additional_mem_pool_size=2Minnodb_log_file_size=5Minnodb_log_buffer_size=8Minnodb_flush_log_at_trx_commit=1innodb_lock_wait_timeout=50----【mysqld】中的配置和單實例的mysqld配置一致，多實例中每個[mysqld]需要有不同的埠號，sock，datadir然後是啟動：/usr/local/mysql/bin/mysqld_mulit--defaults-extra-file=/etc/my.cnfstart1----這里的數字1對應[mysqld1]，關閉就是把start改成stop，啟動所有就是startall其他命令你自己網上查下吧

8. 請問MySQL所謂的支持半同步復制是什麼意思啊，謝謝

http://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign

9. mysql半同步復制適合哪些業務場景

說實話 這個問題 很難回答

同步復制，犧牲很多性能。slave 需要等待master處理結束 不阻塞情況。
非同步性能好，但是不等待master處理結束，不保證數據完整
半同步介於兩者之間。數據可靠性很好，但是略微犧牲性能。

業務場景。。。。 看你資料庫伺服器多屌咯。都能廣泛運用於各種場景。

如果硬要說的話，半同步復制，個人認為不適合大流量高失敗請求的網路游戲數據儲存。更適合流量一般的 非持續性的數據更替吧。比如，網商，網路訂單？

PS:絕不是安利。以前我自己搭建資料庫伺服器。後來維護麻煩，直接用了阿x雲的rds。再無煩惱。用少量金錢解決的大問題。。。。 何必自己辛苦