：在一般的业务架构中，数据库都不会直接服务于终端用户，而是服务于运行业务逻辑的应用程序。所以数据库和业务程序之间出于安全的考虑，会选择使用私有网络。即便如此，为了避免数据库连错，也需要在设置数据库账号时，增加IP来源限制。在一些特定的场景下，如果数据访问必须借助公网来实现，就会将数据库暴漏在公网上。使用公网数据库实例，必须要配置防火墙，否则存在被攻击的隐患。通过iptables我们可以控制访问数据库的来源IP。
权限检查：MySQL提供了多种权限配置，为了方便管理以及避免误操作，一般会将管理权限和访问权限配置成两个不同的账号，禁止使用管理权限作为业务程序访问数据库的账号。通过系统库mysql库的user表可以确认各个账号拥有的权限，尽量避免业务账号拥有super权限；
参数配置
- 内存相关参数：MySQL数据库的内存使用包括两个部分：共享内存与连接独占内存。每一个用户新建连接，数据库都要分配一块固定大小的内存空间保存用户的临时数据，这些空间为单个连接独占。在MySQL实例启动时，系统同时也会预先分配一些实例级别的共享内存空间，例如Innodb_buffer_pool，Innodb_log_buffer_pool等，供所有连接共享。独占内存空间乘以最大连接数加上共享内存空间，我们可以计算出MySQL最大可使用的内存空间，如果超过实际物理内存大小，就存在MySQL进程被Linux操作系统强行oom kill风险，导致实例宕机。MySQL的这些内存空间都可以通过配置参数指定大小，如果超过实际内存空间，应该调整相应参数配置，最常见的是调整Innodb_buffer_pool和最大连接数。
- 频繁卡顿，如果设置过大，会导致数据库实例重启或者故障恢复花费大量的时间。一般，对于使用固态硬盘等高配置的存储设备的数据库，可以将重做日志设置大一些，对于使用机械硬盘的数据库，应该设置小一些，一般在512M到4G之间。innodb_flush_log_at_trx_commit定义了重做日志的刷新节奏，如果该参数非1，会导致数据库宕机重启后丢失部分更新数据，对于数据可靠性要求较高的应用造成严重影响。
- 二进制日志相关参数：binlog 主要用于MySQL集群复制以及故障恢复担任协调者的作用。binlog_format定义了binlog的格式，主要包括ROW、STATEMENT、MIXED三种格式，ROW格式是最安全的一种日志格式，会保证主从数据的严格一致，建议开发者选用ROW格式。但是ROW格式的binlog会占用更多的存储空间，通过expire_logs_days可以控制保存binlog的天数，如果binlog占用的存储空间比例超过50%，则应考虑适当减少binlog的保存天数。sync_binlog 参数定义了binlog刷新硬盘的节奏，如果非1，会导致宕机重启后最近的更新数据丢失。
- 连接数相关参数：MySQL有最大连接数限制max_connections，如果应用连接超过max_connetions限制，则会得到out of max connections异常，无法建立连接。show processlist可以查看当前的连接数，如果接近最大限制，则存在无法新建连接的风险。通过在应用端使用连接池可以控制数据库的连接数。
用户访问
- 慢连接：慢查询数量是最直观的反映数据库处理能力是否满足业务需求的指标。通过设置slow_query_log可以开启慢查询日志，MySQL数据库会将执行时间超过long_query_time的查询记入慢查询日志，如果某个时间段内，慢查询数量急剧增加，则开发者就必须要关注数据库的性能问题，首先就需要进行SQL优化，其次考虑资源是否需要扩容，最后可能需要数据库水平扩展方案，包括创建只读从节点；
- 死锁数量：两个事务涉及的数据库记录有重叠，如果SQL语句的加锁顺序不一致，就会导致事务之间的死锁。虽然MySQL数据库会自动的检测死锁并强制回滚系统认为代价较小的事务，但是死锁的检测与事务回滚都有较大的代价，会严重拖慢数据库的性能，所以当系统中出现大量死锁时，开发者必须引起重视，要分析发生死锁的事务的SQL语句的加锁规则，调整SQL语句。通过show engin innodb status可以查看死锁的相关信息以及系统的处理过程。
3/4 首页 上一页 1 2 3 4 下一页 尾页
