mysql容器化部署更可靠，因能规避系统依赖冲突和字符集不一致问题；须用mysql:8.0镜像、挂载数据卷、设utf8mb4字符集、非3306端口暴露，并按设备类型分表、设复合主键、防连接泄漏、严格权限隔离。
MySQL 容器化部署比手动安装更可靠
在物联网平台中，MySQL 环境最常出问题的不是配置，而是系统依赖冲突和字符集默认值不一致。用 docker run 启动官方镜像能绕过大部分 CentOS/Ubuntu 底层差异，也避免了 mysql_secure_installation 交互式流程导致的自动化失败。
- 优先使用
mysql:8.0镜像（非latest），因 5.7 默认utf8实际是utf8mb3，设备上报含 emoji 或某些传感器型号名会截断 - 必须显式挂载
/var/lib/mysql到宿主机路径，否则容器重启后设备表全丢；推荐用-v /data/mysql:/var/lib/mysql - 启动时加
--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci，否则即使客户端设对了，SHOW CREATE TABLE仍显示utf8 - 暴露端口建议用
-p 3307:3306而非 3306，避免与宿主机已有 MySQL 冲突，尤其边缘网关常预装 MariaDB
建表前必须确认设备数据写入模式
物联网设备数据不是“用户行为日志”，不能直接套用通用日志表结构。高频上报（如每 5 秒一条温湿度）会导致单表急速膨胀，INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 在无主键场景下会失效。
- 每张设备表必须有复合主键：
(device_id, timestamp)，其中timestamp类型用DATETIME(3)（毫秒级），别用TIMESTAMP（时区转换易错） - 禁止为每台设备单独建表——元数据管理成本高，且
SHOW TABLES在千级设备时变慢；按设备类型分表（如sensor_dht22,meter_aml200）更可控 - 如果设备支持断网续传，需预留
is_uploaded TINYINT DEFAULT 0字段，由后台服务异步更新，而非依赖应用层重试逻辑
Python 设备接入脚本要防连接泄漏
很多 demo 代码用 pymysql.connect() 每次写入都新建连接，设备量一上来就触发 Too many connections。真实场景中，连接必须复用，且超时控制比 SQL 本身更重要。
- 用
pymysql.Connection初始化时设autocommit=False和connect_timeout=3，避免设备网络抖动卡死整个写入线程 - 批量写入必须用
executemany()，而非循环execute()；100 条数据单条插入耗时约 120ms，executemany可压到 18ms（实测 8.0 + SSD） - 务必捕获
pymysql.err.OperationalError并检查错误码：1205（死锁）需重试，2013（连接断开）要重建连接，不能统一 except 后 silent ignore
权限隔离比性能调优更优先
设备接入账号不是 DBA 账号。给 INSERT 权限的同时开了 DROP，等于把设备固件升级通道交给了任意一台被黑的终端。
- 创建专用账号时用
CREATE USER 'dev_writer'@'192.168.10.%' IDENTIFIED BY 'pwd123!';，IP 段限制比%更安全 - 只授权具体表：
GRANT INSERT ON iot_db.sensor_dht22 TO 'dev_writer'@'192.168.10.%';，禁用GRANT OPTION - 定期轮换密码可结合 MySQL 8.0 的
ALTER USER ... PASSWORD EXPIRE INTERVAL 90 DAY，避免硬编码在设备固件里
字符集、连接复用、权限粒度——这三处不处理，后面加读写分离或分库分表都是在补漏洞。设备数据一旦错乱或丢失，溯源成本远高于初期多花十分钟配好容器参数。
