Clarify in the secondary index section too that we need to be careful of continuous values

[Tetsuya3850]

Change Request

1. Describe what you find is inappropriate or missing in the existing docs.
   It is carefully cautioned in the docs that we need to be careful not to specify continuous values as primary key (such as auto increment)
   https://docs.pingcap.com/tidb/stable/dev-guide-create-table#guidelines-to-follow-when-selecting-primary-key
   However, it doesn't seem to be emphasized for the secondary index.
   https://docs.pingcap.com/tidb/stable/dev-guide-create-secondary-indexes
   I wonder, for example, it is very common to have an index on a continuous value such as updated_at. As secondary indexes are also just another key value record, won't this also cause hotspots?
   If that is the case I think it will be nicer to also caution that in the secondary index section and also suggest some workaround practices.
   I think the best practices note this point briefly?
   "The situation gets worse when some index values of the continuous written data is also continuous (for example, fields that increase with time, like update time), which creates a few write hotspots and becomes the bottleneck of the entire system."
   https://docs.pingcap.com/tidb/stable/tidb-best-practices

2. Describe your suggestion or addition.
   Caution the usage of continuous value in secondary index section and add suggestions for workaround.

3. Provide some reference materials (such as documents and websites) if you could.
   https://docs.pingcap.com/tidb/stable/dev-guide-create-table#guidelines-to-follow-when-selecting-primary-key
   https://docs.pingcap.com/tidb/stable/dev-guide-create-secondary-indexes
   https://docs.pingcap.com/tidb/stable/tidb-best-practices

[Oreoxmt]

@Icemap Could you please take a look at this?

[Tetsuya3850]

Thank you for checking!

Maybe we can add the same on this page too.
https://docs.pingcap.com/tidb/stable/dev-guide-index-best-practice

[Icemap]

Got it. Let me check it. Good catch! Thanks, @Tetsuya3850.