ElasticSearch 6字段命名规则官方文档查询及实测疑问

Great question—this is a common point of confusion when upgrading from older Elasticsearch versions to 6.x. Let’s break down the official rules and align them with the behavior you’ve observed through testing:

ES 5 and Earlier: Original Field Naming Rules #

First, let’s confirm the rules you found for Elasticsearch 5 and older versions, which are well-documented:

• Field names could not start with an underscore (_)
• Commas (,) and hash symbols (#) were strictly forbidden in field names
• Dots (.) were technically allowed but strongly discouraged (since they imply nested field structures)
• Field names were capped at a maximum of 255 characters

ES 6+: Key Rule Changes (From Official Docs) #

Starting with Elasticsearch 6.x, the team relaxed some restrictions while tightening others, which matches your experimental findings:

1. Underscores, Commas, and Hashes Are Now Permitted #

• You’re correct: field names can now start with an underscore (_). Note that system fields like _id or _source are still reserved, but custom fields starting with _ are fully supported.
• Commas (,) and hash symbols (#) are no longer blocked in custom field names. These restrictions were lifted to give more flexibility in field naming.

2. Dots (.) Are Risky (and Strongly Discouraged) #

Your observation about dots causing occasional errors is spot-on. The official docs emphasize:

• While dots aren’t explicitly blocked, using them can lead to unexpected exceptions like illegal_state_exception or array_index_out_of_bounds_exception.
• The core issue is that Elasticsearch treats dots as separators for nested fields. A field named user.email would be interpreted as a nested user object with a sub-field email—this can cause conflicts if you have a top-level user field, or if your data structure doesn’t match this implicit nested setup.
• Any "working" cases with dots are unsupported edge cases; relying on them can lead to data corruption or indexing failures down the line.

3. Empty String Field Names Are Forbidden #

Empty string field names are explicitly rejected in ES 6+, triggering an illegal_argument_exception. This is a hard restriction called out in the mapping documentation to prevent invalid mapping configurations.

4. Field Name Length Limit Was Relaxed #

The 255-character cap was removed in ES 6+. While there’s no strict documented maximum length, the official docs warn that extremely long field names can hurt performance (due to increased memory usage for storing mappings). It’s still best practice to keep field names concise and descriptive.

Where to Find This in Official Docs #

These changes are covered in two key places in Elasticsearch’s official documentation:

1. 6.x Breaking Changes Guide: This section explicitly calls out the relaxed restrictions on underscores, commas, and hashes, while highlighting the risks of using dots.
2. Mapping Documentation: The mapping docs detail reserved characters, forbidden patterns (like empty strings), and best practices for field naming.

内容的提问来源于stack exchange，提问作者Frederick Zhang