本章节主要从命名、TAG、FIELD、查询等方面介绍GeminiDB Influx使用上的一些规范和建议，用于解决常见的使用错误，低效，难以维护等问题。
术语定义
- 规则：使用时必须遵守的约定。
- 建议：使用时必须考虑的约定。
名词解释
- RP：Retention Policy，即数据保留策略，包含数据保留时长，备份个数等信息。
- 数据对象：数据库、RP、MEASUREMENT、TAG、FIELD。
命名
规则
a. 数据库对象的名称需要以小写字母开头，使用字母或者数字组合，长度不能超过32个字节。
b. 数据库对象的名称长度：<数据库名>.<RP名称>.<MEASUREMENT名称> 总长度不能超过120个字符。
c. 数据库对象的名称不能使用系统保留关键字。
系统保留关键字详情如下：ALL,ALTER,ANY,AS,ASC,BEGIN,BY,CREATE,CONTINUOUS,DATABASE,DATABASES,DEFAULT,DELETE,DESC,DESTINATIONS,DIAGNOSTICS,DISTINCT,DROP,DURATION,END,EVERY,EXPLAIN,FIELD,FOR,FROM,GRANT,GRANTS,GROUP,GROUPS,IN,INF,INSERT,INTO,KEY,KEYS,KILL,LIMIT,SHOW,MEASUREMENT,MEASUREMENTS,NAME,OFFSET,ON,ORDER,PASSWORD,POLICY,POLICIES,PRIVILEGES,QUERIES,QUERY,READ,REPLICATION,RESAMPLE,RETENTION,REVOKE,SELECT,SERIES,SET,SHARD,SHARDS,SLIMIT,SOFFSET,STATS,SUBSCRIPTION,SUBSCRIPTIONS,TAG,TO,USER,USERS,VALUES,WHERE,WITH,WRITE,WARM
d. 数据库对象的名称不能使用中文和特殊字符(["].$,/\0*?~#:|')。
e. 数据库名称不能使用_internal、_kapacitor、_heimdall、_vision、opentsdb等系统使用的数据库名。
建议
a. TAG名称越短越好，每个TAG名称都有索引，索引都会在内存中，名字越短，越节省资源。
b. TAG KEY和FIELD KEY命名不要相同。
TAG
规则
a. 对其使用InfluxQL函数（MAX、MIN、COUNT等）的字段，作为FIELD存储**。**
b. TAG只支持字符串类型，如果存储的值不是字符串类型，作为FIELD存储**。**
建议
a. 使用TAG区分数据比使用MEASUREMENT名称区分性能更好**。**
b. 根据需求设计TIME精度，精度越低性能越好**。**
c. 经常作为查询条件的字段，作为TAG存储。
d. 对其使用GROUP BY的字段，作为TAG存储**。**
FIELD
- 规则： 每个FIELD类型必须保持一致。
- 建议： FIELD不宜太多，每个FIELD的计算都会单独计算，太多当执行模糊查询会导致查询失败。
查询
规则
a. 禁止执行SELECT * FROM进行查询。
b. 查询语句必须带上时间范围限制。
c. 业务上线前，一定要对数据库进行性能压测，评估业务峰值场景下，对数据库的负载情况。
建议
a. 执行查询时，只选择需要返回的字段，不需要的字段不要返回。
b. 查询时间范围越小，查询性能越好。
c. 查询时TAG值越精确查询性能越好。尽量是单时间线查询，即指定所有的TAG值，或者尽量指定越多的TAG值。
d. 在查询中的group by time intervals后增加fill(none), fill(none)作用为：对于没有数据点的时间间隔，不返回任何时间戳和值。针对稀疏数据场景，能大幅降低查询返回结果数据量。
e. 在使用嵌套查询时将时间范围的查询条件放在最外层的查询语句中。
删除
建议： 不要使用DELETE方法删除数据，建议根据需求设置合理的RP，通过RP自动删除数据。
其他方面
- 规则 ：根据业务具体时间线规模、客户端连接数、保留策略数量选择对应的实例规格，规格详情请参考1.3 数据库实例规格。
超规格使用，可能会导致不可预知的问题；严重时有可能导致数据库不可用。
- 建议： 使用ELB连接数据库，详情请参见3.3.2.1 通过负载均衡地址连接实例（推荐）。
- 建议： 如果开启了冷存储，在一个时间段的数据已经转冷后，不建议再写入该时间段的数据，否则会引起未知问题。
