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。再无烦恼。用少量金钱解决的大问题。。。。 何必自己辛苦