从 MySQL 到 TSDB：初学者也能看懂的数据库类型入门
从 MySQL 到 TSDB：初学者也能看懂的数据库类型入门
本文从“TSDB 是不是时空数据库”这个问题出发，介绍关系型数据库、时序数据库、空间数据库、时空数据库，以及键值、文档、图数据库等常见数据库类型，并结合通用软件系统和设备监控场景，说明它们分别适合保存什么数据。
1. 为什么系统中会出现多种数据库？
刚接触后端系统时，很容易产生一个疑问：
系统已经有 MySQL 了，为什么还需要 TSDB？是不是所有数据都放进一个数据库就可以？
理论上，很多数据都可以勉强存进 MySQL；但“能够存储”不等于“适合存储”。
不同数据有不同特点：
- 用户、角色和设备信息结构稳定，需要准确查询和修改；
- 温度、功率等监测数据不断产生，而且主要按时间查询；
- 车辆轨迹同时包含时间和位置；
- 社交关系需要频繁查询“谁认识谁”；
- 缓存数据要求读写速度快，但不一定需要长期保存。
因此，数据库并不是只有一种。数据库类型的区别，本质上是：
它采用什么方式组织数据，以及它最擅长解决哪类查询问题。
2. 先理解：数据库是什么？
数据库可以简单理解为一个“有组织的数据仓库”。
它不仅负责保存数据，还需要支持：
- 新增数据；
- 查询数据；
- 修改数据；
- 删除数据；
- 建立数据之间的关系；
- 保证多人同时操作时数据仍然正确；
- 在数据量很大时依然尽量快速地返回结果。
例如，一个设备管理系统可能需要保存：
设备编号：DEVICE_01 设备名称：1号传感器 所属区域：A区域 设备型号：MODEL_X同时还要保存设备不断上报的数据：
10:00 环境温度 23.1℃ 10:01 环境温度 23.3℃ 10:02 环境温度 23.4℃这两类数据看起来都与设备有关，但它们的结构、更新频率和查询方式完全不同，因此适合使用的数据库也可能不同。
3. 关系型数据库是什么？
3.1 它是什么？
关系型数据库把数据组织成一张张“表”。
一张表通常包含：
- 行：一条完整记录；
- 列：记录中的某个属性；
- 主键：唯一标识一条记录；
- 外键：表示不同表之间的关联。
例如，设备表可以设计为：
| id | device_code | device_name | area_id |
|---|---|---|---|
| 1 | DEVICE_01 | 1号传感器 | 101 |
| 2 | DEVICE_02 | 2号传感器 | 101 |
区域表可以设计为：
| id | area_name | system_name |
|---|---|---|
| 101 | A区域 | 示例系统 |
device.area_id可以关联到area.id，表示某台设备属于哪个区域。
常见的关系型数据库包括：
- MySQL；
- PostgreSQL；
- SQL Server；
- Oracle；
- SQLite。
3.2 为什么叫“关系型”？
这里的“关系”并不只是人与人之间的关系，而是指：
数据通过表、主键和外键建立关联。
例如：
设备表 ↓ area_id 区域表 ↓ system_id 系统表这样可以避免在每条设备记录中重复保存大量区域和项目信息。
3.3 关系型数据库擅长什么？
关系型数据库适合：
- 用户、角色和权限；
- 设备基本信息；
- 项目和区域配置；
- 订单与支付记录；
- 告警规则；
- 审批流程；
- 需要事务保证的数据。
所谓事务，可以通俗理解为：
一组操作要么全部成功，要么全部失败，不能只完成一半。
例如银行转账时：
- 账户 A 扣款；
- 账户 B 加款。
如果只扣款但没有加款，数据就出错了。关系型数据库通常很擅长保证这类操作的一致性。
3.4 SQL 是什么？
SQL 是 Structured Query Language 的缩写，即“结构化查询语言”。
它是操作关系型数据库的常用语言。例如：
SELECTdevice_nameFROMdeviceWHEREarea_id=101;它表示：
查询
device表中，所有属于 101 号区域的设备名称。
关系型数据库擅长保存结构明确、关系清晰、需要频繁修改并要求数据一致性的业务数据。
4. 时序数据库 TSDB 是什么？
4.1 它是什么？
TSDB 是Time Series Database的缩写，即“时序数据库”。
时序数据库专门用于保存：
按照时间持续产生的一系列数据。
例如一个温度传感器每分钟上报一次环境温度：
| 时间 | 点位 | 数值 |
|---|---|---|
| 10:00 | DEVICE_01_TEMPERATURE | 23.1 |
| 10:01 | DEVICE_01_TEMPERATURE | 23.3 |
| 10:02 | DEVICE_01_TEMPERATURE | 23.4 |
每条数据通常包含：
时间戳 + 指标或点位标识 + 数值 + 标签例如：
时间：2026-07-28 10:01:00 点位：DEVICE_01_TEMPERATURE 数值：23.3 设备：DEVICE_01 区域：A区域4.2 TSDB 是某一个具体软件吗？
不是。
TSDB 是一类数据库，不是某个固定产品的名字。
这类似于：
- “关系型数据库”是一类数据库；
- MySQL 是关系型数据库中的一个具体产品。
常见的时序数据库或时序存储系统包括：
- InfluxDB；
- TDengine；
- Apache IoTDB；
- TimescaleDB；
- OpenTSDB；
- Prometheus 的时序存储。
因此，文档只写“使用 TSDB”，只能说明使用了某类时序数据库，不能确定具体产品。
在项目中需要向后端确认：
当前系统具体使用的是哪一种 TSDB？4.3 为什么需要时序数据库？
设备监控数据通常具有以下特点：
- 写入频率高；
- 数据量增长快；
- 历史数据很少修改；
- 大部分查询都带时间范围；
- 经常计算平均值、最大值、最小值和总量；
- 需要自动删除过期数据；
- 需要对历史数据进行压缩和降采样。
例如，1 万个点位每分钟上报一次：
10000 × 60 × 24 = 1440 万条/天如果长期保存，数据量会迅速增长。
MySQL 并非完全不能存这些数据，但随着数据量增大，表分区、索引、归档和查询优化会越来越复杂。TSDB 针对这种“按时间不断追加”的数据做了专门优化。
4.4 TSDB 擅长哪些操作？
1. 持续写入
设备不断上报：
- 温度；
- 湿度；
- 功率；
- 流量；
- 压力；
- 风机转速；
- 设备状态；
- 设备启停状态。
2. 按时间范围查询
例如：
查询 1 号设备过去 24 小时的温度变化。3. 时间聚合
原始数据可能每秒一条，但前端图表不需要显示几十万条记录，可以聚合为：
- 每分钟平均值；
- 每小时最大值；
- 每天总能耗。
4. 自动过期
时序数据库通常支持保留策略，也就是 TTL。
TTL 是Time To Live的缩写，可以理解为“数据有效期”。
例如：
数据保留时间：2 年 超过 2 年：自动删除5. 数据压缩与降采样
降采样指的是将高频数据转换为低频统计数据。
例如：
原始数据：每秒 1 条 保存一年后：只保留每小时平均值这样可以减少存储空间，同时保留长期趋势。
5. 空间数据库是什么？
5.1 它是什么？
空间数据库主要保存和查询“位置、形状和区域”等空间信息。
常见空间数据包括：
- 一个点：设备位置、门店位置；
- 一条线：道路、管线；
- 一个面：行政区域、建筑范围；
- 多边形：园区、地块；
- 三维坐标：楼层、地下管网、三维模型位置。
例如：
设备编号：CAMERA_01 经度：120.20 纬度：31.50空间数据库不仅能保存经纬度，还能完成普通数据库不擅长的空间查询，例如：
- 查询距离某个位置 5 公里内的所有设备；
- 判断某个点是否位于某个园区范围内；
- 计算两条道路是否相交；
- 找到距离当前位置最近的充电站；
- 计算两个区域是否重叠。
5.2 经纬度为什么不能只用普通数字保存？
可以把经纬度分别存成两个数字字段：
longitude = 120.20 latitude = 31.50但如果要计算“附近 5 公里”“点是否在区域内”“两条路线是否相交”，普通数字字段处理起来会比较麻烦。
空间数据库会提供专门的空间数据类型、索引和函数，使这些查询更高效、更准确。
6. 时空数据库是什么？
6.1 它是什么？
时空数据库同时关注两个维度：
- 时间维度：什么时候发生；
- 空间维度：在哪里发生。
例如车辆轨迹：
| 时间 | 经度 | 纬度 | 速度 |
|---|---|---|---|
| 10:00 | 120.20 | 31.50 | 60 |
| 10:01 | 120.21 | 31.51 | 55 |
| 10:02 | 120.23 | 31.52 | 62 |
每一条数据都同时回答：
车辆在什么时间，位于什么位置，当时状态如何？6.2 时空数据库适合哪些场景？
- 车辆轨迹；
- 网约车调度；
- 无人机飞行轨迹；
- 人员移动；
- 物流运输；
- 气象空间分布；
- 卫星遥感；
- 动物迁徙；
- 移动设备定位；
- 城市交通分析。
6.3 时序数据库和时空数据库有什么区别？
时序数据库关心：
某个指标随时间怎么变化。
时空数据库关心：
某个对象在不同时间位于哪里，或者某个区域在不同时间发生了什么。
例如固定传感器设备：
位置长期不变 重点关注温度、状态随时间变化这种数据通常更适合时序数据库。
例如移动中的车辆：
位置不断改变 同时需要分析时间和轨迹这种数据更适合时空数据库。
7. 三种数据库的核心对比
| 对比维度 | 关系型数据库 | 时序数据库 | 时空数据库 |
|---|---|---|---|
| 主要关注 | 业务实体及关系 | 指标随时间变化 | 对象随时间和空间变化 |
| 常见数据 | 用户、设备、订单、配置 | 温度、功率、流量、日志指标 | 车辆轨迹、人员移动、气象分布 |
| 典型查询 | 某用户有哪些权限 | 过去 24 小时平均功率 | 某车辆昨天经过哪些区域 |
| 数据变化 | 支持增删改查 | 主要持续追加 | 持续记录位置和时间变化 |
| 常用索引 | 主键、普通索引、联合索引 | 时间索引、标签索引 | 时间索引、空间索引 |
| 主要优势 | 关系清晰、事务可靠 | 高频写入、时间聚合、TTL | 轨迹和空间范围查询 |
| 应用示例 | MySQL 存业务配置 | TSDB 存监测指标 | 轨迹平台存移动记录 |
8. 其他常见数据库类型
数据库类型并不只有上面三种。下面介绍几类开发中经常遇到的数据库。
8.1 键值数据库
键值数据库使用：
Key → Value的方式保存数据。
例如：
user:1001 → {"name":"张三","token":"abc"}常见产品：
- Redis；
- Memcached。
它适合：
- 缓存；
- 登录状态；
- 验证码；
- 计数器；
- 排行榜；
- 临时数据；
- 分布式锁。
可以把它理解成一个非常快的“字典”。
8.2 文档数据库
文档数据库通常以 JSON 类似的结构保存数据。
例如：
{"deviceCode":"AC_01","deviceName":"1号设备","sensors":[{"type":"temperature","unit":"℃"},{"type":"power","unit":"kW"}]}常见产品：
- MongoDB；
- CouchDB。
它适合：
- 字段经常变化的数据；
- 不同记录结构不完全一致的数据；
- 内容管理；
- 商品详情；
- 用户画像；
- JSON 数据存储。
8.3 图数据库
图数据库使用“节点”和“边”表示数据及关系。
例如：
用户A --关注--> 用户B 用户B --购买--> 商品C 商品C --属于--> 类别D常见产品：
- Neo4j；
- JanusGraph。
它适合：
- 社交关系；
- 知识图谱；
- 推荐系统；
- 风险关系分析；
- 路径查询；
- 组织关系。
图数据库的重点不是保存一张图片，而是保存复杂的“关系网络”。
8.4 搜索引擎型存储
搜索引擎型存储擅长全文检索和日志分析。
常见产品：
- Elasticsearch；
- OpenSearch。
它适合：
- 搜索文章内容；
- 搜索商品；
- 日志检索；
- 聚合分析；
- 模糊匹配；
- 多条件筛选。
例如搜索：
包含“设备故障”关键词的所有告警日志使用 Elasticsearch 通常比直接在 MySQL 中做大规模模糊查询更合适。
9. 为什么一个系统会同时使用多个数据库？
现代系统经常采用“多数据库协作”，原因不是为了炫技，而是不同数据库各自承担最擅长的任务。
以一个通用设备监控系统为例：
图中的分工可以理解为：
- TSDB：保存设备监测数据和实时分析结果；
- MySQL：保存用户、设备、区域、配置和告警规则；
- Redis：保存缓存、登录状态或短期数据；
- 后端服务：根据业务需要组合查询多个数据库。
9.1 MySQL 负责“设备是谁”
例如：
设备编号：DEVICE_01 设备名称：1号传感器 所属区域：A区域 设备型号：MODEL_X9.2 TSDB 负责“设备每个时间发生了什么”
例如：
10:00 环境温度 23.1℃ 10:01 环境温度 23.3℃ 10:02 环境温度 23.4℃9.3 Redis 负责“现在经常要用什么”
例如：
当前登录用户信息 最近一次设备状态 验证码 热点查询结果MySQL 负责描述业务对象“是谁”，TSDB 负责记录对象“随时间发生了什么”，Redis 负责加速“现在经常使用的数据”。
10. 在通用设备监控系统中，哪些数据适合放在哪里？
| 数据内容 | 推荐存储 | 原因 |
|---|---|---|
| 用户账号 | MySQL | 结构稳定，需要权限和事务 |
| 用户角色 | MySQL | 与用户、菜单和权限有关联 |
| 设备名称、型号 | MySQL | 属于设备基础信息 |
| 区域和系统配置 | MySQL | 业务关系明确 |
| 告警规则 | MySQL | 需要修改、启用和停用 |
| 每分钟温度 | TSDB | 持续产生，主要按时间查询 |
| 实时温度 | TSDB | 高频写入，需要趋势和聚合 |
| 设备状态 | TSDB | 随时间变化的监测指标 |
| 实时分析结果 | TSDB | 分析结果随时间持续产生 |
| 异常评分 | TSDB | 需要回看历史分析结果 |
| 登录验证码 | Redis | 有效期短，读写频繁 |
| 当前在线状态 | Redis 或业务缓存 | 需要快速读取 |
| 移动车辆轨迹 | 时空数据库 | 同时依赖时间和空间查询 |
11. 数据从设备到前端的完整流程
执行过程如下：
- 传感器采集设备温度、状态等数据；
- 数据采集服务给每条数据添加时间和点位标识；
- 数据被写入 TSDB；
- 分析服务读取实时数据和历史数据；
- 分析服务生成统计值、趋势结果或异常评分；
- 分析结果也可以继续写入 TSDB；
- 用户打开前端趋势页面；
- 前端通过接口向后端请求数据；
- 后端从 MySQL 查询设备名称、所属区域等基础信息；
- 后端从 TSDB 查询指定时间范围内的监测数据；
- 后端组合结果并返回给前端；
- 前端将数据展示为折线图、柱状图或报表。
12. 如何判断应该使用哪一种数据库？
数据库选型不能只看数据“长什么样”，还要看系统“怎么使用数据”。
可以依次思考以下问题。
12.1 数据是否结构稳定？
如果字段明确，而且记录之间有清晰关系，可以优先考虑关系型数据库。
例如：
用户、角色、设备、项目、订单12.2 是否主要按时间持续追加？
如果数据不断产生，主要查询某段时间内的趋势，可以考虑时序数据库。
例如：
温度、功率、流量、CPU 使用率12.3 是否需要计算距离、范围和轨迹？
如果需要分析位置、区域和移动轨迹，可以考虑空间或时空数据库。
例如：
车辆轨迹、附近设备、区域覆盖12.4 是否主要做缓存和高速读取？
如果数据生命周期短，而且需要极快读取，可以考虑 Redis 等键值数据库。
12.5 是否存在非常复杂的关系网络？
如果经常查询多层关系和路径，可以考虑图数据库。
12.6 是否需要全文搜索？
如果需要对大量文本、日志或商品进行关键词检索，可以考虑 Elasticsearch 等搜索引擎型存储。
13. 初学者容易混淆的地方
13.1 数据有时间字段，不代表必须使用 TSDB
MySQL 表中也可以有created_at和updated_at字段。
是否使用 TSDB，主要看：
- 数据量是否持续快速增长；
- 是否高频写入；
- 是否主要按时间范围查询；
- 是否需要时间聚合、TTL 和降采样。
13.2 数据有经纬度，不代表已经是时空数据库
在 MySQL 中保存两个数字字段，也能记录经纬度。
但如果需要大量执行：
- 附近搜索；
- 范围判断；
- 轨迹分析；
- 路径相交；
就更需要空间索引和专门的空间查询能力。
13.3 TSDB 和数据库表不是同一层级的概念
TSDB 是数据库类型，而表是数据库内部组织数据的一种方式。
不能把它们对比成：
TSDB 和表有什么区别？更合理的对比是：
时序数据库和关系型数据库有什么区别？13.4 一种数据库不一定只能做一件事
例如，某些关系型数据库通过扩展也可以支持：
- 时序数据；
- 空间数据；
- JSON 文档。
但“支持”不等于在所有规模和场景下都最合适。
项目选型还要考虑：
- 数据规模；
- 团队经验；
- 运维成本；
- 查询需求；
- 可靠性要求；
- 现有技术栈。
14. 本次学习总结
通过本次学习，可以建立一套基础认知：
- 关系型数据库使用表来组织业务数据，擅长处理结构化数据、复杂关系和事务；
- 时序数据库 TSDB专门处理随时间持续产生的数据，擅长高频写入、时间查询、聚合、TTL 和压缩；
- 空间数据库重点处理点、线、面、距离和区域；
- 时空数据库同时处理时间和空间，适合车辆、人员、无人机等移动轨迹；
- Redis等键值数据库适合缓存和短期高速数据；
- 文档数据库适合结构灵活的 JSON 类数据；
- 图数据库适合复杂关系网络；
- 搜索引擎型存储适合全文检索和日志查询；
- 一个真实系统可以同时使用多种数据库，让每种数据库负责自己最擅长的工作；
- 在通用设备监控系统中，MySQL 通常保存业务配置，TSDB 保存监测指标和实时分析结果。
后续还可以继续学习：
- MySQL 中的表、主键、外键和索引；
- SQL 的增删改查；
- TSDB 中的时间戳、标签、指标和字段；
- TTL、归档、降采样与冷热数据分层；
- 前端、后端和数据库之间的数据请求流程；
- 项目实际使用的 TSDB 产品及其部署方式。
问题与解答
问题 1：TSDB 是不是一种专门的时空数据库？
我的困惑：
TSDB 的中文名称中带有“时”，而时空数据库也与时间有关，因此容易把二者理解成同一类数据库。
解答：
这个理解不准确。
TSDB 是Time Series Database，中文是“时序数据库”，重点是记录某个指标随时间的变化。
例如：
10:00 指标值 23.1 10:01 指标值 23.3 10:02 指标值 23.4时空数据库则同时关注：
什么时候 + 在哪里例如车辆在 10:00 位于哪个经纬度，10:01 又移动到了哪里。
对于固定位置的传感器、服务器和工业设备，设备位置通常不会频繁变化，系统主要关心它们的温度、负载和状态随时间如何变化，因此通常使用时序数据库，而不是专门的时空数据库。
一句话记忆：
TSDB 看“数值随时间怎么变”，时空数据库看“对象在什么时间位于哪里”。
问题 2：TSDB 是不是某个具体数据库软件的名字？
我的困惑：
文档写了“TSDB”，容易误以为项目中安装了一个名字就叫 TSDB 的数据库。
解答：
TSDB 不是某个固定产品，而是一类数据库的统称。
类似地：
关系型数据库：数据库类型 MySQL：具体产品对应到时序数据库：
时序数据库：数据库类型 InfluxDB、TDengine、IoTDB：具体产品因此，仅看到“系统使用 TSDB”还不能判断具体技术选型，需要进一步向后端确认：
当前项目具体使用的是哪一种时序数据库？一句话记忆：
TSDB 是数据库类别，不是唯一的软件名称。
问题 3：既然 MySQL 也能保存时间和数值，为什么还需要 TSDB？
我的困惑：
只要设计一张包含point_code、value和timestamp的表，MySQL 看起来也能保存设备数据。
解答：
MySQL 确实可以保存时序数据，特别是在数据量较小、采集频率较低时，完全可能满足需求。
但设备监测数据通常具备以下特点：
- 高频持续写入；
- 数据量增长快；
- 大部分查询带时间范围；
- 经常进行平均值、最大值和总量统计；
- 历史数据很少修改；
- 需要自动过期和长期压缩。
TSDB 会针对这些特点进行优化。
因此，区别不是“能不能存”，而是：
当数据量持续增大时，哪一种数据库能够更自然、更高效地完成写入、查询、聚合、压缩和清理。
一句话记忆：
MySQL 也能存时序数据，但 TSDB 是专门为大规模时间序列读写设计的。
问题 4：在通用设备监控系统中，MySQL 和 TSDB 应该如何分工？
我的困惑：
设备信息和设备监测值都属于同一台设备，不容易理解为什么要分别存进两个数据库。
解答：
可以把一台设备的数据分成两类。
第一类是描述设备身份和配置的数据：
设备编号 设备名称 设备型号 所属区域 启用状态这些数据结构稳定，需要修改、关联和权限控制，适合放在 MySQL。
第二类是设备随时间产生的数据：
10:00 指标值 23.1 10:01 指标值 23.3 10:02 指标值 23.4这些数据高频产生，主要用于趋势查询和统计，适合放在 TSDB。
前端查询时，后端可以同时读取两边的数据，再组合成完整结果。
一句话记忆：
MySQL 记录设备“是谁”，TSDB 记录设备“每个时间发生了什么”。