OK - I opened up the query itself…

SELECT `ringtunes`.*, 
count(case when ringtune_history.Action = 'Download' then ringtune_history.Action end) as Org_Downloads, 
count(case when ringtune_history.Action = 'View' then ringtune_history.Action end) as Org_Views, 
count(case when ringtune_history.Action = 'Play' then ringtune_history.Action end) as Total_Plays, 
count(case when ringtune_history.Action = 'Like' then ringtune_history.Action end) as Total_Likes, 
`categories`.`Name` as `Category_Name` FROM `ringtunes` 
LEFT JOIN `ringtune_history` ON `ringtune_history`.`Ringtune_Id` = `ringtunes`.`Id` 
LEFT JOIN `categories` ON `categories`.`Id` = `ringtunes`.`Category` 
WHERE `ringtunes`.`Deleted` = 0 AND `ringtunes`.`Status` = 1 AND `categories`.`Deleted` = 0 AND `categories`.`Status` = 1 
GROUP BY `ringtunes`.`Id` 
ORDER BY `ringtunes`.`Id` DESC 
LIMIT 20; 

The LIMIT 20 doesn’t do anything for you other than restrict the return result rows. It isn’t going to improve the internal performance of the query.

It’s worth mentioning the zeroth rule of DB query optimizers: they do what they’re coded to do, not what you imagine they could do if they were super-smart and clever. Here, you may imagine that LIMIT 20 could apply to the anchor table of the join, ringtunes, and restrict *it* before executing the join. But it doesn’t; MySQL applies LIMIT after the body of query has been otherwise completely processed. But there is a way to use LIMIT to improve query performance as I’ll show below…

The GROUP BY will have to do a full sort on the result of all the joins, and the LEFT JOIN means you’re going to end up with a working set whose rowcount is at least equal to all the rows in the ringtunes table. The WHERE clause will filter out some of the rows, and this result set will then be ordered and GROUP’d.

Depending on how big the ringtunes table is, this is a pretty beefy query that does a ton of joining and active sorting. The COUNTs, even if they may look icky, shouldn’t be a problem.

As for improving performance:

• First, fetch the 20 IDs you want separately. The LIMIT 20 will *not* do this.
• Get rid of the ringtunes.*. This is probably an illegal GROUP BY, as the only allowed select-list members in a GROUP BY are explicitly GROUP’d columns (in this case ringtunes.ID) or the results of aggregates like COUNT(). The results you’ll get are going to be random, and unfortunately MySQL allows this sort of stuff.
• I assume that at least one of the joins is 1:many, as otherwise grouping on ringtunes . ID doesn’t make any sense. Even so, make sure you’re joining on indexed columns.

So, a possible new query could be something like

SELECT ringtunes.ID, -- get rid of ringtunes.* - fetch later if needed 
count(case when ringtune_history.Action = 'Download' then ringtune_history.Action end) as Org_Downloads, 
count(case when ringtune_history.Action = 'View' then ringtune_history.Action end) as Org_Views, 
count(case when ringtune_history.Action = 'Play' then ringtune_history.Action end) as Total_Plays, 
count(case when ringtune_history.Action = 'Like' then ringtune_history.Action end) as Total_Likes, 
`categories`.`Name` as `Category_Name`  
FROM (SELECT DISTINCT ringtunes.ID FROM ringtunes WHERE 
ringtunes.deleted = 0 and ringtunes.status = 1 ORDER BY ringtunes.ID DESC LIMIT 20) AS r_id 
JOIN ringtunes ON r_id.id = ringtunes.id 
LEFT JOIN `ringtune_history` ON `ringtune_history`.`Ringtune_Id` = `ringtunes`.`Id` 
LEFT JOIN `categories` ON `categories`.`Id` = `ringtunes`.`Category` 
WHERE `categories`.`Deleted` = 0 AND `categories`.`Status` = 1 
-- ringtunes WHERE filters are in the subquery above 
GROUP BY `ringtunes`.`Id` 
ORDER BY `ringtunes`.`Id` DESC; 

This may look ickier as it has the initial subquery to fetch your 20 ordered IDs, but it should be faster, and is at least a legal GROUP BY.

If ringtunes . ID is actually the PK for ringtunes, you can get rid of the DISTINCT above.

1. Proper structure of tables and normalization
2. Skmetimes(very rare) denormalization or creation of reporting tables(lets say count and last access date for users to be updated on logins)
3. Creation of proper indexes
4. Making the sql engine work with specific indexes in your queries. Simple short queries usually are slower than long queriea where you guide the engine by forcing it to use indexes based on the conditions you write

Most important is to know relarional database theory basics and indexes and utilizing them. The last point that gives the magnitudes faster queries needs years of experience to be.learned.

Some possibilities:

1. The INSERT itself may be slow. If you have a really huge table with lots of secondary indexes, adding new rows could be slow (although if the server is otherwise not busy, a single-row INSERT shouldn't take more than a few dozen milliseconds on reasonably modern, healthy hardware even if the table is huge). Note that adding the data to the table isn't the slow part as much as finding out where to add the data in inserts - in other words, INSERT can actually be a READ-intensive operation if you have a lot of indexes, particularly if they're "cold" (ie, not in the buffer pool).

2. There may be an issue with I/O. INSERT in MySQL involves updates to the xact log and in-memory changes to buffer pool pages. Base tables and indexes are typically worked on in RAM and flushed to disk over time (at least in InnoDB). Once the INSERTing transaction commits (and immediately if you have AUTOCOMMIT=ON), the INSERT's db operation will hit the xact/redo log.

3. You may have a very busy server and don't have enough threads configured for what you're doing with the server. Check the variable "innodb_thread_concurrency" - if it's a lot smaller than the number of routinely active database connections, you may need to increase it (or just put up with slow inserts if you can't increase it). MySQL will queue database operations and not finish them until other operations have "cleared" if the server is busy in a manner similar to how an OS multitasks processes on a CPU.

4. There may be other things locking the table. This is more likely the case with MyISAM, but I've seen it happen with InnoDB on occasion; there appear to be cases where a table or page can effectively be locked and INSERTs will wait for these operations to clear.

I’m not exactly sure how “PDO” works, but a few things that can help in the application level:

• If you’re routinely loading large numbers of records, use a “multi-row” insert statement, ie

INSERT INTO MYTAB (colnames) VALUES 
 (row1), (row2), …, (rowN); 

You would just build up a huge string in your client code and send the string in a single “execsql()” call (or whatever it is in your programming language). Note that if you’re building a very long string, you may need to change max_allowed_packet to allow longer query strings.

I’ve found that an insert of a thousand rows can be nearly as fast as inserting a single row in many databases, so this approach is almost “free”.

• If you can’t do the above, at least do your INSERTs in a large transaction. Most database engines - including MySQL - have some notion of AUTOCOMMIT, and in most of them, it’s always “on”, which means every INSERT has an implied COMMIT. To only COMMIT at the end of your load, either do AUTOCOMMIT OFF, or (my recommended way), do

START TRANSACTION; 
<insert1>; 
<insert2>; 
… 
<insertN>; 
COMMIT; 

(This will work whether AUTOCOMMIT is ON or not.)

This is often several dozen times faster than having a COMMIT - implicit or otherwise - after every INSERT.

If possible, you may be able to combine the above approaches to load your data quickly.

I'm still learning about MySQL, so feel free to correct me if some of these are inaccurate. These are some tips that I picked up from the folks at Percona:

• Disk is too slow

Are you RAIDing your drives? Using RAID10 is useful not just for performance reasons, but for reliability of drive failures. If you control your hardware, also consider upgrading to SSD or FusionIO.

Link: http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-vs-fusionio/

• Disk is overloaded

If you are running a logging database on the same machine as your production database, then both those databases will have to compete for the same resources. If possible, break your database apart into more functional units to prevent contention.

• InnoDB transactions are flushing too often

If you are using InnoDB, consider setting your innodb_flush_log_at_trx_commit to 2. Transaction flushes default to 1 (write and flush after every commit). Setting the flush log variable to 2 will not flush so aggressively, but will cost some reliability.

If you’re not concern [sic] about ACID and can loose [sic] transactions for last [sic] second or two in case of full OS crash than set this value. It can dramatic [sic] effect especially on a lot of short write transactions.

Link: http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

• InnoDB log file is too small

The default for the InnoDB log file size is an extremely small, conservative value so that it is guaranteed to work on any system, but not work efficiently on most systems.

Link: http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/

• Tables are too large

Can your largest tables be broken apart? Breaking your million-row tables into partitions will effectively reduce the algorithmic complexity of table operations, as well as make more efficient use of MySQL's buffers, at the expense of making JOINs and SELECTs across partition boundaries more expensive.

Link: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html
Link: http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/

MySQL 5.7 is painfully slow and lacks many of the tools that I’m used to on Oracle systems. I’m stuck with it until my ISP goes to something newer/better. I take a defensive approach.

1. Try to keep your table joins to two tables if when possible. 2nd normal form may perform better, but requires you to do more maintenance to keep everything in sync.
2. Use EXPLAIN PLAN often. Just because you add an index doesn’t mean the optimizer will use it.
3. When you find a join that works, create a view and use it instead. You don’t want to reinvent the wheel.
4. If you need to do a three way join, try to join two of the tables first through a view. That may give you some control on the join order.
5. Consider creating intermediate results tables. Again, in a three way join situation, you want to reduce as many rows as you can. You might have to break it up into two steps. You can do your order by as a separate step as well.
6. Consider changing ISP hosts or upgrading your hardware. You might not be able to change your application to get better performance.
7. If you have a choice, check out MySQL 8. It has analytic functions and may run faster. But if you are dependent on an ISP, you’re out of luck.

(Asked to answer)

I'll answer from the perspective of SQL Server queries. Other database management systems operate similar enough that the generics of the answer still apply but the details will differ.

SQL is a so-called declarative programming language. This means that the developer doesn't tell the computer HOW to perform the task, but rather tells the computer WHAT RESULTS they want and then the computer figures out how to achieve those results.

If a query is slow, there can be multiple broad categories of reasons.

Perhaps you just asked for a huge load of work. Doing some complex arithmetic on all five billion sales records of the past five years will generally never be faster than at least the time it takes to read this five billion rows of data from disk (unless someone anticipated the question and did some smart prep work).

Perhaps the database is not properly designed for performance. Optimal performance means making very smart decisions on your indexing strategy, so that a high number of important queries can reap the benefits of a small set on indexes. And sometimes you'll need to tell users that certain queries simply cannot be optimized without causing too many unwanted side effects.

And perhaps the database management system made a bad choice when deciding how to execute the query. This can be infuriating because we have very limited options to influence these choices. But on the other hand, once we know how and why such bad decisions are made it often becomes fairly trivial to fix the actual underlying root cause.

For the second and third category, it is absolutely essential that you learn to read and understand the execution plan (for SQL Server), or is equivalent (for other databases). For SQL Server, I highly recommend reading “SQL Server execution plans, 3rd edition” (not the earlier editions, please), which is available as a free download from RedGate, or for money as a printed copy from Amazon.

Use the EXPLAIN statement to see the query plan. The explained plan shows how the table(s) are scanned and what indexes are used. The indexes are used to JOIN tables or filter WHERE clauses. Any full table scans are good candidates for new indexes.

Use the ANALYZE TABLE Statement to update planner statistics. This records about how many rows a table has. It tracks the key cardinality used by an index, e.g. the age column has only 5 values (17, 18, 19, 20, 21) and is not a good index to pull many rows.

• Optimizing Queries with EXPLAIN
• EXPLAIN Output Format - The Query Plan

1. See EXPLAIN Join Types
2. See possible_key - indexes available
3. See key - the index selected for use by query planner

• ANALYZE TABLE - Update Planner Statistics

First: try to normalize the database. Database normalization is very important when you reach certain amount of rows.

Second: allways use numbers. If you have to make SELECTs and you have to order by a field o make a condition with a field, try to code that field as a number.

Third: indexes. That's your word: indexes. Every field you use in a WHERE or in an ORDER BY, must be indexed.

Fourth: sometimes, is better to make something by programming and don't make everything with the database core.

I'ver worked with a table with 50 millions rows (yes, 50 millions). And I made a join with that table and two other tables with 8 millions rows each. The time was less than a second.

Sorry for my spelling mistakes.

I have seen some good answers so I’d like to add my few observations:

1. As Greg Kemnitz suggested, consider wisely to avoid the ‘*’ queries as waste of time and resources as result render takes a lot of time (mostly not needed);
2. Here I add a note: the fact of using a view instead of a table is a useful short cut as if you repeat a lot of similar queries the system will not cache them while e View can help consistently;
3. As Mark Twaine suggested, development phase is a time where you struggle to get results while real life is another thing; like the first point, you have to clean up your code and your SQL calls to avoid bottlenecks;
4. In addition to this latter point, there are tools to assess where you may have space to improve like the EXPLAIN command or the MySQLCheck that check both logs and queries to adjust configuration variables to fit to your needs but first you need to revise your code and your SQL calls as you may know much more easily where there may be space for improvement;
5. As you may see in other environments, assess your changes as each may be a benefit or not and for this you may use the ‘time’ function of your system;
6. My last suggestion is not to write clear text queries not for a matter of elegance but for showing that you know what you are doing and your code is stable and mature.

It depends on what you mean by "with" an OR condition…

Ie

Cola = xxx and colb in (111,222,333,….)

Cola between xxx and yyy or cola….

Cola…. Or colb….

…

How complex is the selection, what are the cardinalities involved….

Some situations will be assisted by the creation of multi column indexes, others would benefit from indexes on separate columns…

As always look at the statistics of the data involved and test the performance of possible Indexes…

You should also consider if consolidation of the OR conditions is possible. .e.g using BETWEEN or range conditions, or CASE/grouping tables to conform the data being selected… and appropriate use of sub queries or even UNION queries to accomplish the desired processing…

There are lots of ways to do query optimization for MySQL. Here are three:

1. Turn on the slow query log in MySQL. This gets you a specific log file of every query that isn’t optimal. Setting this option can be tricky so my advice is to set it and then explicitly run a crappy query to make certain that the logging is actually turned on. You may have to do this a few times to be certain.
2. Understand that MySQL uses a single index for query and ordering so if you want to query by one column and order by another both those columns need to be present in the index. This is probably the most common mistake people make.
3. Run the explain option on our query i.e. EXPLAIN SELECT * FROM articles WHERE posted=1; Explain runs the query planner and shows you the result. Be particularly careful when you see the FILE SORT option which literally means “MySQL will write this to an external file on disk and then use a separate sort tool on it”. Anytime the sort isn’t done in memory, well, that’s a problem.
4. Look into development environment specific performance tools like New Relic which often have query monitoring.
5. Bear in mind that date queries when you store date-times such as “SELECT * FROM articles WHERE DATE(created_at) = ‘2017–06–01’” get translated into range queries under the hood and range queries are expensive. I often store both a created_at and a date_created_at value on my databases to get around this since usually date queries are what people want more than date-time queries.
6. If you really have performance issues then consider sharding data across multiple tables but that’s an advanced approach which is harder to discuss / describe.

Query optimization include various steps. Few are as follows:

Optimizing SELECT Statements

Queries, in the form of SELECT statements, perform all the lookup operations in the database. Tuning these statements is a top priority, whether to achieve sub-second response times for dynamic web pages, or to chop hours off the time to generate huge overnight reports.

Besides SELECT statements, the tuning techniques for queries also apply to constructs such as CREATE TABLE...AS SELECT, INSERT INTO...SELECT, and WHERE clauses in DELETE statements. Those statements have additional performance considerations because they combine write operations with the read-oriented query operations.

In MySQL NDB Cluster 7.2 and later, the NDB storage engine supports a join pushdown optimization whereby a qualifying join is sent in its entirety to NDB Cluster data nodes, where it can be distributed among them and executed in parallel. For more information about this optimization, see Conditions for NDB pushdown joins.

The main considerations for optimizing queries are:

• To make a slow SELECT ... WHERE query faster, the first thing to check is whether you can add an index. Set up indexes on columns used in the WHERE clause, to speed up evaluation, filtering, and the final retrieval of results. To avoid wasted disk space, construct a small set of indexes that speed up many related queries used in your application.
• Indexes are especially important for queries that reference different tables, using features such as joins and foreign keys. You can use the EXPLAIN statement to determine which indexes are used for a SELECT.
• Isolate and tune any part of the query, such as a function call, that takes excessive time. Depending on how the query is structured, a function could be called once for every row in the result set, or even once for every row in the table, greatly magnifying any inefficiency.
• Minimize the number of full table scans in your queries, particularly for big tables.
• Keep table statistics up to date by using the ANALYZE TABLE statement periodically, so the optimizer has the information needed to construct an efficient execution plan.
• Learn the tuning techniques, indexing techniques, and configuration parameters that are specific to the storage engine for each table. Both InnoDB and MyISAM have sets of guidelines for enabling and sustaining high performance in queries.
• Avoid transforming the query in ways that make it hard to understand, especially if the optimizer does some of the same transformations automatically.
• If a performance issue is not easily solved by one of the basic guidelines, investigate the internal details of the specific query by reading the EXPLAIN plan and adjusting your indexes, WHERE clauses, join clauses, and so on. (When you reach a certain level of expertise, reading the EXPLAIN plan might be your first step for every query.)
• Adjust the size and properties of the memory areas that MySQL uses for caching. With efficient use of the InnoDB buffer pool, MyISAM key cache, and the MySQL query cache, repeated queries run faster because the results are retrieved from memory the second and subsequent times.
• Even for a query that runs fast using the cache memory areas, you might still optimize further so that they require less cache memory, making your application more scalable. Scalability means that your application can handle more simultaneous users, larger requests, and so on without experiencing a big drop in performance.
• Deal with locking issues, where the speed of your query might be affected by other sessions accessing the tables at the same time.

Subquery Optimization

Certain optimizations are applicable to comparisons that use the IN operator to test subquery results (or that use =ANY, which is equivalent). This section discusses these optimizations, particularly with regard to the challenges that NULL values present. The last part of the discussion suggests how you can help the optimizer.

Optimizing INFORMATION_SCHEMA Queries

Applications that monitor databases may make frequent use of INFORMATION_SCHEMA tables. Certain types of queries for INFORMATION_SCHEMA tables can be optimized to execute more quickly. The goal is to minimize file operations (for example, scanning a directory or opening a table file) to collect the information that makes up these dynamic tables.

Try to use constant lookup values for database and table names in the WHERE clause

You can take advantage of this principle as follows:

• To look up databases or tables, use expressions that evaluate to a constant, such as literal values, functions that return a constant, or scalar subqueries.
• Avoid queries that use a nonconstant database name lookup value (or no lookup value) because they require a scan of the data directory to find matching database directory names.
• Within a database, avoid queries that use a nonconstant table name lookup value (or no lookup value) because they require a scan of the database directory to find matching table files.

Optimizing Data Change Statements

This section explains how to speed up data change statements: INSERT, UPDATE, and DELETE. Traditional OLTP applications and modern web applications typically do many small data change operations, where concurrency is vital. Data analysis and reporting applications typically run data change operations that affect many rows at once, where the main considerations is the I/O to write large amounts of data and keep indexes up-to-date. For inserting and updating large volumes of data (known in the industry as ETL, for “extract-transform-load”), sometimes you use other SQL statements or external commands, that mimic the effects of INSERT, UPDATE, and DELETE statements.

Optimizing Database Privileges

The more complex your privilege setup, the more overhead applies to all SQL statements. Simplifying the privileges established by GRANT statements enables MySQL to reduce permission-checking overhead when clients execute statements. For example, if you do not grant any table-level or column-level privileges, the server need not ever check the contents of the tables_priv and columns_priv tables. Similarly, if you place no resource limits on any accounts, the server does not have to perform resource counting. If you have a very high statement-processing load, consider using a simplified grant structure to reduce permission-checking overhead.

Other Optimization Tips

This section lists a number of miscellaneous tips for improving query processing speed:

If your application makes several database requests to perform related updates, combining the statements into a stored routine can help performance. Similarly, if your application computes a single result based on several column values or large volumes of data, combining the computation into a UDF (user-defined function) can help performance. The resulting fast database operations are then available to be reused by other queries, applications, and even code written in different programming languages.

• To fix any compression issues that occur with ARCHIVE tables, use OPTIMIZE TABLE.
• If possible, classify reports as “live” or as “statistical”, where data needed for statistical reports is created only from summary tables that are generated periodically from the live data.
• If you have data that does not conform well to a rows-and-columns table structure, you can pack and store data into a BLOB column. In this case, you must provide code in your application to pack and unpack information, but this might save I/O operations to read and write the sets of related values.
• With Web servers, store images and other binary assets as files, with the path name stored in the database rather than the file itself. Most Web servers are better at caching files than database contents, so using files is generally faster. (Although you must handle backups and storage issues yourself in this case.)
• If you need really high speed, look at the low-level MySQL interfaces. For example, by accessing the MySQL InnoDB or MyISAM storage engine directly, you could get a substantial speed increase compared to using the SQL interface.
• Replication can provide a performance benefit for some operations. You can distribute client retrievals among replication servers to split up the load. To avoid slowing down the master while making backups, you can make backups using a slave server.

A2A, thanks...

I don't know the exact MySQL query optimizer internals, but it appears to be a fairly standard statistics-driven cost-based query optimizer. For a general description of cost-based query optimizers, this wiki page is a decent start: Query optimization, but at the end of the day, what query optimizers want to do is find the route to the query answer that visits the fewest number of pages possible.

A related post I wrote a bit ago:

How does SQL execute a query?

Anyway, to start with you have to define exactly what query optimizers do; they're most analogous to a programming language compiler. They take your SQL input, after it's been processed by a parser, and build an "execution plan" data structure that is used by the execution part of the RDBMS to actually answer the query.

In query optimizing, there are a lot of considerations that an optimizer has to account for in its analysis:

1. How to order any joins? Join order is the sequence used to walk through the tables in the query as the join is executing. As a rule, you want the tables that produce the smaller working set visited earliest, especially for the "anchor table" in the join, as it (or a subset of it if there's other WHERE-clause predicates on it) will have to be fully traversed by the query. In MySQL, the STRAIGHT_JOIN hint lets the user dictate left-to-right FROM-clause join order.
   
2. What indexes to use, or is it cheaper to skip the index and use a tablescan? Note that indexes aren't always best, particularly if a query ends up visiting a significant chunk of the table's rows. The first two considerations are informed by table statistics, so it's a good idea to run ANALYZE TABLE to update them, especially if the relative sizes of tables change (ie, a table suddenly becomes large or has a bunch of rows deleted).
   
3. What types of join algorithms can be considered? Different RDBMSs have different join algorithm capabilities. MySQL is limited in that it only supports Nested loop join, although it can use Nested loop over index/PK to do the lookup on the target table. So, in this criterion, MySQL's query optimizer has it easy :)
   
4. Whether temporary structures can be used versus always hitting the disk/buffer pool for rows every time we visit the table?
   
5. Does the storage engine or storage media have any special properties that may make certain routes better than others? For instance, InnoDB uses a table's primary key to organize base table data, making lookups using the PK particularly fast versus using secondary indexes (and this is why you should _always_ have a defined PK on any nontrivial InnoDB table). Also, some optimizers, and apparently some versions of MySQL, can account for the fact that a table is stored in SSD versus spinning disk. This would make a difference if joining two tables stored on different storage media.
6. How to figure out all this stuff without taking a long time simply doing the analysis? This is a far bigger consideration than one may think, especially for complex joins involving lots of tables as the solution space can get huge very easily. Query optimizers have heuristics that prune unpromising query paths quickly so they don't have to bother doing a full analysis on them, but like any heuristic of this kind, this occasionally means the best query plan gets thrown out.

What you need is to make sure your queries have the indexes they need. If you have an index on some fields but a query needs an index on a different field, then adding the index needed will be an improvement.

One thing which can make queries faster which have an appropriate index is if it has all the fields the query needs indexed. Sometimes people have indexes for each of the field queried, but all of their indexes only index one field.

For example, if you search names by first and last name then having an index on both first and last name will make that query faster than two indexes one on the first name and one on the last name.

Keep in mind the order of the fields in the index. A query can use an index which has more fields than it needs, as long as the fields that it needs are listed before the fields it does not need indexed. So if you sometimes query by first and last name, but sometimes query by last name alone, then an index on last name and first name (in that order) can be used by both queries without keeping an index on last name alone.

Less important but also a concern is don’t have too many indexes. Every index has to be updated for every change to the database. If you index every combination of fields which could be useful but are not actually used then you are slowing down your database on updates without any benefit to queries.