定时限制 ≠ 越快越好；而是每一次数据库读写事务，必须在预先规定的截止时间（时限）之前完成；如果超时，就算失败，系统不能无限等待。 这类数据库一般归类为实时数据库（RTDB），大量用在嵌入式工控、自动驾驶、航空电子、机器人、PLC 等硬实时嵌入式场景。
1. 和普通数据库最大区别
普通PC/服务器数据库（MySQL、SQLite常规用法）：
尽力执行查询，多久完成不确定；可以等待、排队、重试，没有硬性时间红线，优先保证数据一致性。
带定时限制的嵌入式实时数据库：
每个数据库操作（增删改查、事务）都附带截止时间（deadline）。
- 必须在截止时间内执行完毕；
- 一旦超过时限，直接判定事务失效，不能阻塞任务继续运行；
- 很多场景下：时限优先级 > 绝对的数据一致性。
2. “定时限制”两层核心含义
（1）时间约束：操作存在明确时限
系统设计者预先定义：
- 单次查询最多允许耗时：例如 ≤1ms、≤5ms
- 事务执行截止时刻 嵌入式系统很多是周期性任务（10ms周期采集传感器、控制电机）：
如果数据库查询卡死、耗时超过周期，控制指令来不及下发 → 设备失控。 所以数据库操作不能无限阻塞任务线程。
（2）时限违规有明确处理策略
不能像普通数据库一直等IO、等待锁： 可选策略举例：
- 超时直接中止事务，放弃本次读写；
- 放弃非关键数据，优先保障高优先级实时事务；
- 拒绝新事务，防止队列堆积导致大面积超时； 而不是持续等待锁、磁盘IO。
3. 嵌入式场景为什么特别强调定时限制？
嵌入式典型特征：
- 多任务抢占、实时调度（RMS/EDF实时调度） 任务有严格周期，数据库调用属于任务内部动作，如果DB操作耗时不可控，会破坏整个系统实时性；
- 很多存储介质速度不稳定（Flash、SPI Flash、eMMC） 随机读写时延波动很大；普通文件数据库时延不可预测；
- 系统往往带安全约束（工业控制、车载） 超时引发控制失效属于功能安全风险。
举个直观例子： 自动驾驶嵌入式单元，每20ms周期读取路况状态数据库：
- 规定数据库读取定时限制：最大5ms
- 如果某次读取花了8ms，超出定时限制 → 不能一直等，必须立刻终止读取，使用上一帧缓存数据，保证控制算法按时运行。
4. 延伸：容易混淆的概念区分
- 定时限制（timing constraint）：执行必须满足截止期限（实时属性）
- 吞吐量：单位时间处理多少请求（普通数据库关注）
- 响应时间：平均耗时（只是参考，不能保证最坏情况）
定时限制关注最坏情况下的执行时延有上界，追求时延可预测性（有界时延）。
5. 落地层面为满足定时限制，嵌入式实时数据库会做的设计
- 尽量内存数据库，减少低速Flash访问；
- 禁止无等待的长事务，事务设计短小；
- 采用可抢占锁、限时锁，避免任务长时间阻塞；
- 不使用复杂索引、不支持复杂大查询（避免时延爆炸）；
- 提供超时参数，每次调用API可以传入最大等待时间；
- 避开垃圾回收、后台异步刷盘等不可控后台操作。
定时限制是实时数据库的核心特征，指数据库事务不仅要求逻辑正确，还要求必须在规定的截止时间内完成执行；若超出时限，即使事务逻辑无误也视为失败。嵌入式实时系统具有时间关键特性，数据库操作时延不可预测会导致实时任务错过调度时限，引发系统失效，因此数据库操作需要满足定时限制，保障时间可预测。
注意：本文归作者所有，未经作者允许，不得转载
