Tag Info

New answers tagged

0

MySQL still (I thought they were fixing this) requires that the left most part of an index is used in the query: http://dev.mysql.com/doc/refman/5.6/en/multiple-column-indexes.html Yes, you want the highest cardinality first always. Be aware that like oracle, innodb stores its indexes in clustered leafs off the primary index, so any secondary index call is ...


3

Use a composite index: INDEX(confirmada, codTipoTransaccion, idTransaccionOriginal, idTransaccion) The columns can be in any order, so I recommend shuffling them to meet other need(s) and/or facilitate removing some other index from t2. If you need to discuss this further, please provide SHOW CREATE TABLE for each table. Edit For JOIN ... ON ...


2

The Maintenance Plan task can reorganize indexes and that should have some benefit for you. Likely, however, you will reorganize more than necessary using that approach. You should look at Ola Hallengren's solution for Maintenance at: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html


1

Can the Reorganize Index task (maint' plan or ssis package) be used to 'performance tune? Performance tuning is an art. You should avoid knee jerk performance tuning methods - instead you should try to narrow down your investigation. Is this an adequate step of triage for degraded application/query performance? It may or may not be, depending on ...


-1

One thing to keep in mind is that a clustered index is your entire table. It includes every column. Dropping your existing clustered index to rebuild a new one is going to results in a lot of IO. With that in mind, the best way to make this go quicker is anything you can do to increase your IO speeds. Dropping nonclustered indexes and rebuilding those ...


1

Let's walk through the steps. This will make some of the suggestions so far not significant. Scan 2.6 million rows out of 4-5M. Please verify by finding out how many rows have store_id = 1. Scan 2.6 million rows out of 4-5M again. (Yes, a single pass with an OR would be better since there is no way to make use of INDEX(store_id, data_index), which is ...


0

SELECT * , MATCH (`title`) AGAINST ('tax in work') * 1.65 AS `titlescore` , ( ( CASE WHEN time >=1432173380 THEN 21 WHEN time >=1432162580 THEN 18 WHEN time >=1432097780 THEN 15 WHEN time >=1431903380 THEN 11 WHEN time >=1431320180 THEN 7 ELSE 0 END ) * 1.75 ...



Top 50 recent answers are included