High Performance MySQL, third Editionby Baron Schwartz, Peter Zaitsev, and Vadim Tkachenko are an Index of the best solution?
An index isn ' t always the right tool. At a-level, keep-in-mind-indexes is most effective when they help the storage engine find rows without adding m Ore work than they avoid. For very small tables, it's often more effective to simply read all the rows in the table. For medium to large tables, indexes can is very effective. For enormous tables, the overhead of indexing, as well as the work required to actually with the Indexes,can start to add u P. In such cases you might need to choose a technique that identifies groups of rows that is interesting to the query, in stead of individual rows. You can use the partitioning for this purpose; See Chapter 7.//partition if You had lots of tables, it can also make sense to create a metadata table to store some Charac Teristics of interest for your queries. For example, if-you-execute queries that perform aggregations-over-rows in a multitenant application whose data is Partiti oned to many tables, you can record which users of the system ARe actually stored in each table, thus letting you simply ignore tables The that don ' t has information about those users. These tactics is usually useful only at extremely large scales. In fact, this is a crude approximation of what Infobright does. At the scale of terabytes, locating individual rows doesn ' t make sense; Indexes is replaced by Per-block metadata. Creating a Metadata information table to query for some of the features that need to be used to perform data queries that need to aggregate multiple applications across multiple tables requires that the metadata for "which user's information is stored in which table" is not significant, and that the definition of a single record is insignificant. Therefore, block-level metadata technology is often used to replace the index
Indexes (also called "Keys" in MySQL)
