ORACLE审计

Oracle审计(Audit)主要用于记录用户对数据库所做的操作,基于配置的不同,审计的结果会放在操作系统文件中或者系统表中。
默认情况下,使用管理员权限连接实例,开启及关闭数据库是会强制进行审计的,其它的基础的操作则没有进行审计。
在一些安全性要求比较高的环境是需要做一些审计的配置的。

MySQL性能优化最佳实践 - 06 MySQL设计与开发最佳实践

表结构设计的核心思想是什么?

  1. 表及表字段只增不减,即不删除表,不删除字段,只做增加。
  2. 使用innodb存储引擎,支持事务,MVCC,行级锁,更好的恢复性,更高效的IO,更先进的缓存,更先进的写策略。高并发下性能更好,对多核,大内存,SSD等硬件支持更好。
  3. 自增主键,推荐用独立于业务的AUTO_INCREMENT列或全局ID生成器做代理主键。
  4. 拆开宽表,便于运维,加快变更速度,提高查询性能,节省IO和内存。
  5. 控制单表数据量,纯INT不超过1000W,含VARCHAR不超过500w。建议单库不超过300-400个表。
  6. 控制列数据,越短越好,单表不超50个纯INT字段,VARCHAR(10)不超20个字段,单表字段数上限控制在20-50个。
  7. 表和字段加注释。
  8. 使用推荐的字段类型:
    • 时间 timestamp
    • 日期 date
    • IP int unsigned INET_ATON('127.0.0.1') INET_NTOA(ip)
    • 小数 decimal
    • 尽量不用text/blob/char,用varchar
    • 字段只有true or false,用tinyint
    • 非负数值,用unsigned
    • 默认值不能用null,数字类型用default 0,字符类型用defalut ''
  9. 不在数据库里存图片
  10. 禁用外键

MySQL性能优化最佳实践 - 05 MySQL核心参数优化

back_log参数的作用

指定MySQL可能的TCP/IP的连接数量(一个TCP/IP连接占256k),默认是50。
当MySQL主线程在很短的时间内得到非常多的连接请求,该参数就起作用,之后主线程花些时间(尽管很短)检查连接并且启动一个新线程。
back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。如果系统在一个短时间内有很多连接,则需要增大该参数的值,该参数值指定到来的TCP/IP连接的侦听accept队列的大小。
不同的操作系统在这个accept队列大小上有它自己的限制,设定back_log高于你的操作系统的限制将是无效的。

参考值:

back_log=300
# 或
back_log=500

MySQL性能优化最佳实践 - 04 MySQL优化之Linux系统层面调优

MySQL中出现存SWAP,主要会是哪些原因?

  1. 没设置内核参数sysctl.conf中的vm.swappiness=0

    # 在CentOS 6.4及更新版本的内核中设置vm.swappiness=0,有可能会导致MySQL数据库所在的系统出现内存溢出(OOM),
    # 可将vm.swappiness设置成1
    vm.swappiness = 1
    
    # CentOS 7.x中
    ## 查找到存在vm.swappiness参数的配置文件
    find /usr/lib/tuned -name '*.conf' -type f -exec grep "vm.swappiness" {} \+
    #----------------------------------------------------------
    /usr/lib/tuned/latency-performance/tuned.conf:vm.swappiness=10
    /usr/lib/tuned/throughput-performance/tuned.conf:vm.swappiness=10
    /usr/lib/tuned/virtual-guest/tuned.conf:vm.swappiness = 30
    #----------------------------------------------------------
    # 把以上3个文件中的vm.swappiness的值都修改为0或1
    
  2. 没配置MySQL的配置参数memlock
    这个参数会强迫mysqld进程的地址空间一直被锁定在物理内存上,对于os来说是非常霸道的一个要求。要用root帐号来启动MySQL才能生效。

  3. 没关闭NUMA

MySQL性能优化最佳实践 - 03 MySQL服务器优化

如何配置一个进程只跑在单个CPU上?

CPU性能调优方法之一:把进程或线程绑定在单个CPU上,这可以增加进程的CPU缓存速度,提高它的内存I/O性能。方法如下:

# 启动MySQL,将该进程绑定到CPU1上
taskset -c 1 mysqld_safe --defaults-file=/u01/conf/my3306.cnf &

# 使用sysbench压测工具查看CPU绑定后效果
drop database test;
create database test;

sysbench /usr/local/share/sysbench/tests/include/oltp_legacy/select.lua \
--oltp-table-size=100000 --mysql-table-engine=innodb --db-driver=mysql \
--mysql-user=root --mysql-password=root123 --mysql-port=3306 \
--mysql-host=10.245.231.202 --mysql-db=test \
--events=0 --time=60 --oltp-tables-count=20 --report-interval=10 --threads=2 prepare

sysbench /usr/local/share/sysbench/tests/include/oltp_legacy/select.lua \
--oltp-table-size=100000 --mysql-table-engine=innodb --db-driver=mysql \
--mysql-user=root --mysql-password=root123 --mysql-port=3306 \
--mysql-host=10.245.231.202 --mysql-db=test \
--events=0 --time=60 --oltp-tables-count=20 --report-interval=10 --threads=2 run

MySQL性能优化最佳实践 - 02 MySQL数据库性能衡量

测试服务器(或虚拟机)的QPS峰值

利用sysbench压测工具模拟SELECT操作

# 已有test库的话先drop掉
drop database test;
create database test;

# prepare准备阶段,构建压测环境
sysbench /usr/local/share/sysbench/tests/include/oltp_legacy/select.lua \
--oltp-table-size=20000 --mysql-table-engine=innodb --db-driver=mysql \
--mysql-user=root --mysql-password=root123 --mysql-port=3306 \
--mysql-host=10.245.231.202 --mysql-db=test \
--events=0 --time=60 --oltp-tables-count=20 --report-interval=10 --threads=2 prepare

# 开始压测
sysbench /usr/local/share/sysbench/tests/include/oltp_legacy/select.lua \
--oltp-table-size=20000 --mysql-table-engine=innodb --db-driver=mysql \
--mysql-user=root --mysql-password=root123 --mysql-port=3306 \
--mysql-host=10.245.231.202 --mysql-db=test \
--events=0 --time=60 --oltp-tables-count=20 --report-interval=10 --threads=2 run

sysbench 1.0.5 (using bundled LuaJIT 2.1.0-beta2)

Running the test with following options:
Number of threads: 2
Report intermediate results every 10 second(s)
Initializing random number generator from current time


Initializing worker threads...

Threads started!

[ 10s ] thds: 2 tps: 8087.29 qps: 8087.29 (r/w/o: 8087.29/0.00/0.00) lat (ms,95%): 0.34 err/ s: 0.00 reconn/s: 0.00
[ 20s ] thds: 2 tps: 6949.28 qps: 6949.28 (r/w/o: 6949.28/0.00/0.00) lat (ms,95%): 0.35 err/ s: 0.00 reconn/s: 0.00
[ 30s ] thds: 2 tps: 7251.71 qps: 7251.71 (r/w/o: 7251.71/0.00/0.00) lat (ms,95%): 0.34 err/ s: 0.00 reconn/s: 0.00
[ 40s ] thds: 2 tps: 6927.19 qps: 6927.19 (r/w/o: 6927.19/0.00/0.00) lat (ms,95%): 0.35 err/ s: 0.00 reconn/s: 0.00
[ 50s ] thds: 2 tps: 7387.64 qps: 7387.64 (r/w/o: 7387.64/0.00/0.00) lat (ms,95%): 0.32 err/ s: 0.00 reconn/s: 0.00
[ 60s ] thds: 2 tps: 10171.21 qps: 10171.21 (r/w/o: 10171.21/0.00/0.00) lat (ms,95%): 0.26 err/ s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            467780
        write:                           0
        other:                           0
        total:                           467780
    transactions:                        467780 (7795.29 per sec.)
    queries:                             467780 (7795.29 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.0008s
    total number of events:              467780

Latency (ms):
         min:                                  0.11
         avg:                                  0.25
         max:                                 27.63
         95th percentile:                      0.34
         sum:                             119092.82

Threads fairness:
    events (avg/stddev):           233890.0000/242.00
    execution time (avg/stddev):   59.5464/0.00