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，避免硬编码在设备固件里
字符集、连接复用、权限粒度——这三处不处理，后面加读写分离或分库分表都是在补漏洞。设备数据一旦错乱或丢失，溯源成本远高于初期多花十分钟配好容器参数。
