正文： 技术对比：
| | Oracle | McAfee |
| 试用版本 | 5.5 or higher | 5.1 or higher |
| 是否免费 | charge | free |
| 是否动态开关 | yes | yes |
原理对比：由于Oracle的Audit Plugin是基于 5.5新推出的 Audit API ，日志的内容受制于API提供的信息。同时也必须基于5.5及更高版本。由于McAfee的Audit Plugin是基于THD的offset，从内存对象中直接获取信息，因此日志可以获取更多的内核信息。同时，只要能够得到offset，理论上就能够支持所有mysql版本（即其他branch版本） 日志格式：Oracle：XML格式，信息仅限于connection_id ，如果需要具体的用户名信息，需要反查日志获取connection event 得到IP和用户。总体来说非常鸡肋，日志内容基本和general log 没有差别
MaCfee： json格式，显示的记录了用户名和IP，以及涉及的表名。 由于是json格式，也能够方便的把日志导入 Mongo等其他NoSQL进行分析能够比较直接的看到操作信息，也便于分析
{"msg-type":"activity","date":"1352258108848","thread-id":"1","query-id":"6","user":"root","priv_user":"root","host":"localhost","cmd":"show_variables","objects":[{"db":"information_schema","name":"/tmp/#sql_2e54_0","obj_type":"TABLE"}],"query":"show global variables like '%audit%'"} 日志体积：Oracle： 1659269行 日志大小 292M = 每一千行日志 = 0.180K 团购每天Questions = 163330688 句 = 28GMaCfee：1419020行 日志大小 431M = 每一千行日志 = 0.311K 团购每天Questions = 163330688 句 = 48G Oracle由于记录的信息较少，因此文件体积也较小 性能比较：MaCfee：基于percona 5.1.66Oracle： 基于5.5.28-enterprise-commercial-advanced-logSlowlog：基于percona 5.1.66 ， long_query_time =0 时，用于比较plugin相较slowlog之间的性能差异测试方法：AutoPerformanceTest脚本，CPU-Bound 模式测试结果：见下表，单位是QPS。 Base表示没有开启Audit时的基准性能； 红色数字表示开启后，相较基准的性能百分比。
| Concurrency | MaCfee Base | Slow log | | MaCfee Audit | | Oracle Base | Oracle Audit | |
| 1 | 4.79 | 438.03 | % | 307.43 | 63% | 428.65 | 414.99 | 97% |
| 2 | 876.68 | 870.44 | 99% | 774.27 | 88% | 874.26 | 858. | 98% |
| 3 | 1396.44 | 1266.13 | 91% | 1119.77 | 80% | 1321.3 | 1272.78 | 96% |
| 4 | 1830.44 | 14.84 | 90% | 13.28 | 76% | 1719.58 | 1650.44 | 96% |
| 5 | 2297.53 | 1965 | 86% | 1699.57 | 74% | 2142.41 | 2030.47 | 95% |
| 6 | 2703.67 | 2293.4 | 85% | 1744.2 | 65% | 2575.47 | 2388.21 | 93% |
| 7 | 3114.53 | 2521.79 | 81% | 1548.47 | 50% | 29.08 | 2653.88 | 90% |
| 8 | 3539.27 | 2737.86 | 77% | 1479.03 | 42% | 3338.17 | 3044.49 | 91% |
| 9 | 3919.51 | 2875.65 | 73% | 1475.47 | 38% | 3748.98 | 3253.33 | 87% |
| 10 | 4330.8 | 2887.48 | 67% | 1491.87 | 34% | 4136.68 | 3428.16 | 83% |
| 11 | 4672.05 | 2670.53 | 57% | 1484.56 | 32% | 4488.6 | 3576.04 | 80% |
| 12 | 4971.3 | 2335.08 | 47% | 1375.84 | 28% | 4777.9 | 3969.61 | 83% |
| 13 | 4976.72 | 2138.46 | 43% | 1301.13 | 26% | 4802.9 | 4072.96 | 85% |
当long_query_time = 0时，开启slowlog会对并发性能产生较大影响。在9并发时达到吞吐量极限。猜测是slowlog内部有一个排他的mutex，导致了并发性能无法上升。MaCfee在开启Audit后，性能下降了 74%左右，并在6并发时就达到了极限。可见该Plugin对于CPU的损耗非常大。 原因应该和slowlog一致。Oracle相比之下就稍好，性能下降在85%-90%之间。测试期间，两个plugin的IO util都在5%左右，可见日志的buffered sequence write并不是目前的瓶颈。 总结：
Oracle的Audit Plugin：功能较弱，基本等同于general log，不便于分析。居然还要收费，比较吭爹。
MaCfee的Audit Plugin：信息详尽，但是性能在高并发时很大的损耗。不具备线上使用的条件。bitsCN.com
下载本文
