文章851
标签121
分类10

[转载] 新手必看:一步到位之InnoDB

作/译者:叶金荣(imysql#imysql.com>),来源:http://imysql.com,欢迎转载。

前言:MySQL发展到今天,InnoDB引擎已经作为绝对的主力,除了像大数据量分析等比较特殊领域需求外,它适用于众多场景。然而,仍有不少开发者还在“执迷不悟”的使用MyISAM引擎,觉得对InnoDB无法把握好,还是MyISAM简单省事,还能支持快速COUNT(*)。本文是由于最近几天帮忙处理discuz论坛有感而发,希望能对广大开发者有帮助。

1. 快速认识InnoDB

InnoDB是MySQL下使用最广泛的引擎,它是基于MySQL的高可扩展性和高性能存储引擎,从5.5版本开始,它已经成为了默认引擎。
InnODB引擎支持众多特性:

a) 支持ACID,简单地说就是支持事务完整性、一致性;
b) 支持行锁,以及类似ORACLE的一致性读,多用户并发;
c) 独有的聚集索引主键设计方式,可大幅提升并发读写性能;
d) 支持外键;
e) 支持崩溃数据自修复;
InnoDB有这么多特性,比MyISAM来的优秀多了,还犹豫什么,果断的切换到InnoDB引擎吧 :)

2. 修改InnoDB配置选项

可以选择官方版本,或者Percona的分支,如果不知道在哪下载,就google吧。
安装完MySQL后,需要适当修改下my.cnf配置文件,针对InnoDB相关的选项做一些调整,才能较好的运行InnoDB。
相关的选项有:

#InnoDB存储数据字典、内部数据结构的缓冲池,16MB 已经足够大了。
innodb_additional_mem_pool_size = 16M

#InnoDB用于缓存数据、索引、锁、插入缓冲、数据字典等
#如果是专用的DB服务器,且以InnoDB引擎为主的场景,通常可设置物理内存的50%
#如果是非专用DB服务器,可以先尝试设置成内存的1/4,如果有问题再调整
#默认值是8M,非常坑X,这也是导致很多人觉得InnoDB不如MyISAM好用的缘故
innodb_buffer_pool_size = 4G

#InnoDB共享表空间初始化大小,默认是 10MB,也非常坑X,改成 1GB,并且自动扩展
innodb_data_file_path = ibdata1:1G:autoextend

#如果不了解本选项,建议设置为1,能较好保护数据可靠性,对性能有一定影响,但可控
innodb_flush_log_at_trx_commit = 1

#InnoDB的log buffer,通常设置为 64MB 就足够了
innodb_log_buffer_size = 64M

#InnoDB redo log大小,通常设置256MB 就足够了
innodb_log_file_size = 256M

#InnoDB redo log文件组,通常设置为 2 就足够了
innodb_log_files_in_group = 2

#启用InnoDB的独立表空间模式,便于管理
innodb_file_per_table = 1

#启用InnoDB的status file,便于管理员查看以及监控等
innodb_status_file = 1

#设置事务隔离级别为 READ-COMMITED,提高事务效率,通常都满足事务一致性要求
transaction_isolation = READ-COMMITTED 
在这里,其他配置选项也需要注意:

#设置最大并发连接数,如果前端程序是PHP,可适当加大,但不可过大
#如果前端程序采用连接池,可适当调小,避免连接数过大
max_connections = 60

#最大连接错误次数,可适当加大,防止频繁连接错误后,前端host被mysql拒绝掉
max_connect_errors = 100000

#设置慢查询阀值,建议设置最小的 1 秒
long_query_time = 1

#设置临时表最大值,这是每次连接都会分配,不宜设置过大 max_heap_table_size 和 tmp_table_size 要设置一样大
max_heap_table_size = 96M
tmp_table_size = 96M

#每个连接都会分配的一些排序、连接等缓冲,一般设置为 2MB 就足够了
sort_buffer_size = 2M
join_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M

#建议关闭query cache,有些时候对性能反而是一种损害
query_cache_size = 0

#如果是以InnoDB引擎为主的DB,专用于MyISAM引擎的 key_buffer_size 可以设置较小,8MB 已足够
#如果是以MyISAM引擎为主,可设置较大,但不能超过4G
#在这里,强烈建议不使用MyISAM引擎,默认都是用InnoDB引擎
key_buffer_size = 8M

#设置连接超时阀值,如果前端程序采用短连接,建议缩短这2个值
#如果前端程序采用长连接,可直接注释掉这两个选项,是用默认配置(8小时)
interactive_timeout = 120
wait_timeout = 120

3. 开始使用InnoDB引擎

修改完配置文件,即可启动MySQL。启动完毕后,在MySQL的datadir目录下,若产生以下几个文件,则表示应该可以使用InnoDB引擎了。

-rw-rw---- 1 mysql mysql 1.0G Sep 21 17:25 ibdata1
-rw-rw---- 1 mysql mysql 256M Sep 21 17:25 ib_logfile0
-rw-rw---- 1 mysql mysql 256M Sep 21 10:50 ib_logfile1

登录MySQL后,执行命令,确认已启用InnoDB引擎:

(root:imysql.cn:Thu Oct 15 09:16:22 2009)[mysql]> show engines;
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine     | Support | Comment                                                        | Transactions | XA   | Savepoints |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB     | YES     | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |

接下来创建一个InnoDB表:

(root:imysql.cn:Thu Oct 15 09:16:22 2009)[mysql]> 
CREATE TABLE my_innodb_talbe(
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(20) NOT NULL DEFAULT '',
passwd VARCHAR(32) NOT NULL DEFAULT '',
PRIMARY KEY(id),
UNIQUE KEY `idx_name`(name)
) ENGINE = InnoDB;

有几个和MySQL(尤其是InnoDB引擎)数据表设计相关的建议,希望开发者朋友能遵循:

a) 所有InnoDB数据表都创建一个和业务无关的自增数字型作为主键,对保证性能很有帮助;
b) 杜绝使用text/blob,确实需要使用的,尽可能拆分出去成一个独立的表;
c) 时间戳建议使用 TIMESTAMP 类型存储;
d) IPV4 地址建议用 INT UNSIGNED 类型存储;
e) 性别等非是即非的逻辑,建议采用 TINYINT 存储,而不是 CHAR(1);
f) 存储较长文本内容时,建议采用JSON/BSON格式存储;

PHP 脚本 `#!/usr/bin/env php` 写法的好处

在 PHP 脚本的开头使用 #!/usr/bin/env php 是一种常见的做法,它被称为“shebang”行。这种写法在 Unix/Linux 系统中用于指定脚本的解释器。以下是使用这种写法的主要好处:

1. 灵活性

1.1 自动查找 PHP 解释器

#!/usr/bin/env php 使用 env 命令来查找当前环境中的 php 解释器。这意味着无论 PHP 安装在系统的哪个位置,脚本都能够找到并使用正确的解释器。这在多版本 PHP 环境中尤为有用。

1.2 环境兼容性

这种写法使得脚本在不同的系统和环境中具有更好的兼容性。无论是 /usr/bin/php 还是其他路径,只要 php 在用户的 PATH 环境变量中,脚本都能正常运行。

2. 可执行权限

2.1 直接运行脚本

通过在脚本开头添加 shebang 行,用户可以直接在命令行中运行该脚本,无需明确调用 PHP 解释器。例如:

./script.php

而不需要使用:

php script.php

这使得脚本更具可用性和便捷性。

3. 脚本可移植性

3.1 一致性

使用 #!/usr/bin/env php 可以使脚本在不同开发环境(如本地开发、测试和生产环境)中保持一致。这减少了因环境差异导致的错误。

3.2 支持不同操作系统

在不同的 Unix/Linux 系统(如 Ubuntu、CentOS)上,env 命令和 php 解释器的路径可能不同。使用这种方式可确保脚本在多种操作系统上都能正常执行。

4. 更好的代码组织

4.1 明确性

将解释器放在脚本的第一行可以清楚地表明该文件的类型和用途,便于其他开发者理解和使用。

5. 便于调试

5.1 统一入口

使用 shebang 行可以确保在执行脚本时使用相同的 PHP 版本,这在调试和开发过程中能够减少因版本差异导致的问题。

示例

以下是一个简单的 PHP 脚本示例,使用了 #!/usr/bin/env php

#!/usr/bin/env php
<?php
echo "Hello, World!\n";
?>

在命令行中,您可以通过设置执行权限,然后直接运行:

chmod +x script.php
./script.php

大规模网站如何抗压力

大规模网站面临的压力主要来自于高并发请求、数据访问、用户交互等因素。为了保证网站在高流量情况下的稳定性和响应速度,可以采取以下策略和技术:

1. 架构设计

1.1 分层架构

采用分层架构将不同功能模块分开,如前端、应用层和数据层。这有助于管理流量并提高系统的可维护性。

1.2 微服务架构

将大型应用拆分为多个小型、独立的服务,每个服务负责特定功能。这样可以灵活扩展和部署,提高系统的抗压能力。

2. 负载均衡

2.1 使用负载均衡器

通过负载均衡器(如 Nginx、HAProxy、AWS ELB)将请求分配到多个后端服务器,均衡负载,避免单点故障。

2.2 DNS 负载均衡

利用 DNS 轮询将请求分发到多个服务器,提高可用性和性能。

3. 缓存策略

3.1 数据缓存

使用内存缓存(如 Redis、Memcached)存储频繁访问的数据,减少数据库访问压力。

3.2 页面缓存

使用页面缓存技术(如 Varnish)缓存静态页面,提高响应速度。

3.3 CDN(内容分发网络)

使用 CDN 将静态资源分发到离用户更近的节点,减少服务器负担,提高加载速度。

4. 数据库优化

4.1 数据库分库分表

将数据分散到不同的数据库和表中,减轻单个数据库的负载。

4.2 读写分离

使用主从复制,将写操作和读操作分开,主库处理写请求,从库处理读请求。

4.3 索引优化

确保表中适当字段有索引,以提高查询效率。

5. 异步处理

5.1 消息队列

使用消息队列(如 RabbitMQ、Kafka)处理耗时任务,异步处理请求,提高响应速度。

5.2 后台任务

将一些非即时的处理放到后台进行,用户请求后立即返回响应。

6. 安全措施

6.1 防火墙和 DDoS 防护

使用防火墙和 DDoS 防护服务(如 Cloudflare)监控和防御恶意流量,保护服务器。

6.2 请求速率限制

实施请求速率限制(Rate Limiting),防止恶意攻击和过高请求频率。

7. 性能监控和日志分析

7.1 实时监控

使用监控工具(如 Prometheus、Grafana)实时监控系统性能,及时发现问题。

7.2 日志分析

定期分析日志,识别流量峰值和性能瓶颈,进行优化。

8. 自动扩展

8.1 云服务的自动扩展

利用云服务提供商的自动扩展功能,根据流量自动增加或减少服务器实例。

8.2 容器化管理

使用 Kubernetes 等容器编排平台,方便管理和扩展微服务。

9. 压力测试

9.1 定期压力测试

使用工具(如 Apache JMeter、Locust)进行压力测试,评估系统在高并发下的表现,并根据结果进行优化。

9.2 性能基准

定期进行性能基准测试,确保在高流量情况下的稳定性和响应速度。

[踩坑实践] Swoole dispatch_func 自定义分配worker 进程

swoole 的分配worker 进程方式有很多 轮询 争抢 空闲 等等.

因为业务的需求, 我们的服务需要根据用户uid 分配 worker 进程做到用户操作排队.

dispatch_func 自定义分配worker进程方法, 真实让我又爱又恨.

好处不多说 满足业务需求, 从此实现用户操作 单进程排队的效果.

坑也不少, 第一个踩的坑 空包处理 return -1, 没想到结果非常惨 Error: Too many open files[24]

可以看下以前的文章 [Error: Too many open files[24]][1]

今天有一个坑 换了个业务 但也需要用 dispatch_func
心跳包 或 keepalive 两种检测连接方法都失效了....
原因还是 return 负数 我 return -100 仍然不给力 ....
改成随便一个worker 就 ok 了 棒棒哒~

Swoole 报错 NOTICE swFactoryProcess_finish (ERROR 1004): send 76 byte failed,

记录下swoole 抛错

 NOTICE  swFactoryProcess_finish (ERROR 1004): send 76 byte failed, because connection[fd=40]

表示连接已经被关闭了,所以send会失败, 客户端的问题跟服务端没关系 , 当然 如果你fd 用错了 就呵呵了

https://group.swoole.com/question/106029

">