纯文本日志多数小区每天只有几MB到几十MB，一年几GB到几十GB；真正把存储撑大的，往往是抓拍图片、索引副本和监控视频。
小区门禁日志一天能产生多少条记录？先把账算清
门禁日志不是单一文件,它至少分三块：通行事件日志、设备状态日志、抓拍图片或人脸特征值，前两块是结构化文本，第三块才是体积大户。
业内专家指出,门禁日志单条体积主要由字段数量、编码方式和是否存图片决定，只记录时间、卡号、设备号、门点、结果，单条通常很小；一旦加入姓名、照片URL、人脸特征、开门方式、温度、身份证号等字段，单条就会明显膨胀。
单条门禁日志到底占多少字节
- 刷卡、二维码、纯文本事件：常见在150字节到400字节之间。
- JSON格式、字段较多：可能到500字节到1KB。
- 人脸特征值：通常几百字节到几KB，取决于算法厂商。
- 抓拍图片：单张从几十KB到几百KB，是纯文本的成百上千倍。
- 设备心跳、离线告警：条数多，但单条小，通常可忽略。
不同规模小区的日增记录量级
通行记录和户数、门点数、通行策略有关，一个门禁点可能记录“进”和“出”两条，也可能合并成一条，单元门、地下车库门、小区大门都算。
| 小区类型 | 日通行记录量级 | 纯文本日增量 | 带抓拍日增量 |
|---|---|---|---|
| 300户小型小区 | 几千条 | 几MB | 几十MB到几百MB |
| 1000户中型社区 | 1万到3万条 | 十几MB | 几百MB到1GB |
| 3000户大型社区 | 3万到10万条 | 几十MB | 1GB以上到数GB |
表格里的数字是量级参考,不是精确值，实际要看早晚高峰、访客比例、外卖快递通行频次，一个外卖骑手一天多次进出，也会推高记录数。
小区门禁日志和监控录像数据量对比：谁更占硬盘
直接说结论：纯门禁日志通常远小于监控录像，但带抓拍图的门禁系统可能接近甚至超过部分低码率视频。
纯日志、抓拍图、视频的体量关系
- 纯文本日志：每天几MB到几十MB，一年几GB到几十GB。
- 抓拍图片：如果每次通行都抓拍，每天可能几千到几万张，日增几百MB到几GB。
- 监控视频：单路高清摄像头一天常达数GB到十几GB，多路叠加后才是存储主力。
- 人脸特征库：底库数量有限，增量不大，但备份和索引会占空间。
为什么只看数据库行数会误判
很多人只查SELECT COUNT()，看到每天几万条就紧张，几万条纯文本并不大，真正占空间的是：
- 二级索引、唯一索引、组合索引。
- 数据库主从副本、binlog、归档日志。
- 未压缩的抓拍图片。
- 长期不清理的历史分区。
- 云数据库的自动备份和快照。
把这几项加起来,实际占用可能是裸数据的数倍。
北京小区门禁日志数据量有多大？地域差异不大但场景不同
北京小区门禁日志数据量有多大,答案不在城市名，而在小区形态，大型社区、胡同院落、保障房小区、城中村出租房，通行频次完全不同。
决定数据量的不是城市，而是门点和通行策略
- 北京大型社区：户数多、门点多，但很多居民通勤规律，早晚高峰集中。
- 老旧小区：门禁改造后可能只有大门和单元门，记录量中等。
- 城中村或出租房集中区：人员流动大，访客和租客频繁进出，日记录可能更高。
- 高端封闭小区：访客登记严格，人脸抓拍比例高，图片存储更明显。
地域影响的是通行习惯和流动人口比例,不改变单条日志体积，同样1000户，北京和南方城市的数据量差异，通常小于“是否存抓拍图”带来的差异。
门禁日志存储一年需要多大硬盘？价格成本怎么估
先给一个可套用的估算公式：
年容量 ≈ 日记录数 × 单条字节 × 365 × 索引副本系数
索引副本系数可以按1.5到3倍粗估，带图片时，要单独加图片容量。
纯文本年容量估算示例
假设某小区每天3万条纯文本记录,单条300字节。
- 裸数据：3万 × 300字节 ≈ 9MB/天。
- 一年裸数据：约3.3GB。
- 加索引、副本、备份：可能到5GB到10GB。
- 如果每天还有2000张抓拍图,每张100KB，则图片日增约200MB，一年约70GB。
这个例子说明,纯日志不吓人，图片才吓人。
本地硬盘、云存储、对象存储怎么选
- 本地硬盘：适合已有监控主机或机房的小区，4TB监控盘能装很多纯日志，但要注意RAID和坏道。
- 云数据库：适合无人值守、远程管理，成本按实例规格和存储计费。
- 对象存储：适合存抓拍图片和归档日志，低频型、归档型比标准存储便宜不少。
- 冷热分离：最近30天热查，3个月到1年温存，更久归档。
价格成本因厂商、地域、存储类型不同而变化，多数云厂商都有公开阶梯价，先算容量，再比单价和取回费用，不要只看月租。
实操：查表大小和日志目录
MySQL查表大小：
SELECT table_name,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = '你的门禁库'
ORDER BY size_mb DESC;
PostgreSQL查表大小：
SELECT pg_size_pretty(pg_total_relation_size('access_log'));
Linux查日志目录：
du -sh /var/log/dooraccess/
find /var/log/dooraccess -type f -name ".log" -mtime +30 -exec du -ch {} + | tail -1
配置日志轮转：
/var/log/dooraccess/.log {
daily
rotate 30
compress
missingok
notifempty
copytruncate
}
老旧小区门禁日志数据量怎么计算？四步实操
老旧小区设备杂、门点少、数据可能没集中，按下面四步算，基本不会偏。
第一步：摸清设备和门点
列出门禁控制器、读卡器、人脸机、道闸、单元门数量，每个门点每天可能产生进出两类记录。
第二步：抽样统计七天通行量
从数据库按天分组：
SELECT DATE(create_time) AS day, COUNT() AS cnt FROM access_log WHERE create_time >= DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day;
看工作日和周末差异,取中间值作为日均记录数。
第三步：判断是否带抓拍和人脸
查表里是否有image_url、face_feature、snap_path
字段，有抓拍就单独统计图片目录大小：
find /data/snap -type f -mtime -7 -exec du -ch {} + | tail -1
第四步：套公式并设保留期
纯文本按年容量公式算,图片按日均张数 × 单张大小 × 保留天数算，最后加30%余量给索引和临时文件。
门禁日志保留多久合规又不浪费
据《网络安全法》第二十一条，网络日志留存不少于六个月，门禁日志如果属于网络运行日志，通常要参考这个底线，据《个人信息保护法》第六条，处理个人信息要最小必要，存储期限要最短。
行业共识认为,门禁日志保留周期应同时满足安全审计、物业纠纷追溯和个人信息保护，实操可以这样分层：
- 纯文本通行日志：保留6到12个月。
- 抓拍图片：保留30到90天，除非有特殊安全需求。
- 人脸特征值：跟底库绑定，离职或退租后及时删除。
- 设备心跳日志：保留7到30天，主要用于排障。
- 归档数据：压缩后转对象存储，设生命周期规则。
门禁日志的体量,核心看纯文本还是带图带视频；算清日增和保留期，绝大多数小区不需要盲目堆硬盘。
关于小区门禁日志数据量的常见问题
小区门禁日志数据量到底有多大？会影响系统性能吗？
纯文本门禁日志多数小区每天几MB到几十MB,一年几GB到几十GB，对现代数据库不算大，影响性能的往往是未分区、未清理、索引过多、抓拍图直接存数据库，把通行日志按天或按月分区，图片放对象存储，查询和写入会稳很多。
门禁日志和监控录像数据量对比，哪个更值得扩容？
监控录像通常远大于纯门禁日志,单路高清视频一天数GB到十几GB，多路叠加后增长很快，门禁日志只有在全量抓拍、长期不清理时才会明显膨胀，扩容前先查视频存储和图片目录，再决定加硬盘还是买云存储。
北京小区门禁日志数据量有多大？需要买专用服务器吗？
北京小区门禁日志数据量同样取决于户数、门点、通行频次和是否存抓拍图，多数中小社区纯文本日志用普通服务器或云数据库即可，不需要专用高配服务器；大型社区如果带人脸抓拍和高并发写入，才需要独立存储和分区表。