Brittman: so what would.

 
Kovalcik: The explains would be identical

Boehne: Are you saying my schema changed?

Brittman: Nope, i am saying that your index statistics may have

Brittman: Thus, you may see a different optimization strategy, different indexes used

Brittman: You might even see something done in 5.5 that wasnt possible in 5.1 and want to turn that off

Baell: How would they have changed?

Brittman: Scott0_: by restarting mysqld, or running “show table status” or lots of ways

Ikkela: I read through all the migration guide form 5.1 to 5.5 and didn’t find anything notable that I could turn off

Cante: I doubt that would have an impact

Brittman: Do you still have the old server to compare explain on it?

Clusky: I’ve restarted the previous server many times and the queries still run the same speed

Brittman: Scott0_: https://www.percona.com/blog/2011/10/06/when-does-innodb-update-table-statistics-and-when-it-can-bite/

Pilling: I could but the query is built with the application, not by hand

Brittman: Scott0_: turn on the general log for a minute, load the site, turn it off

Stegmann: I doubt this is an issue of just restarting the server and losing indexed data

Brittman: Scott0_: now you have the query instead of guesses

Robinsons: Im not guessing I know that its not from the indexing

Brittman: Run explain and the query a few times on old/new: select sql_no_cache .

Brittman: You might then say “hm, i see something called index merge is now being used but wasn’t before, maybe i can test with that off in my session or replace the indexes with compound index”

Brittman: Or that a different index is used, which you “fix” by running ****yze table, or dropping a silly index

Kuhr: Xgc: vegivamp: Willette: the only problem is, the data is 6.5+ million rows

Cockram: Wouldn’t that have been mentioned in the upgrade guide?

Cogill: As a new feature which could cause problems?

Brittman: Scott0_: this applies when you are not upgrading due to tranient statistics samples

Brittman: Scott0_: it also applies during upgrades.

Krewson: And idnex merge is an optimization, which shouldn’t be a default config

Warring: I have one index and its very strict

Brittman: Scott0_: no more help until you take steps to help your self

Commons: Which is why I doubt that’s what’s happening

Brittman: Scott0_: i am saying you know where to start now, so get to work

Makarewicz: I know well that its not the index

Pesta: I built the index and I use the index as I should

Brittman: Ok then it must be a problem with my.cnf, hopefully someone here can spot it for you

Pulos: That’s what I was asking

Yoxall: I could understand hunting the problem like you’ve mentioned if it’s a mess of indexes and different queries potentially spanning multiple indexes

Orea: But this is far simpler

Houben: Which is why I was focusing on the potential for multicore optimization because I read that 5.5 has benefits in ways 5.1 didn’t

Burghard: And that fresh install 5.5 may actually be slower than 5.1

Brittman: It is also much faster

Johansson: So my goal was maybe to chalk it up to that and then try to make use of the thread parameters

Braff: My server also has double the RAM now

Parfait: It should be a lot faster, but it seems to have gotten slower only on the mysql portion, other services are fast as expected

Kolp: Makes me wonder if I should have upgraded to 5.5

Baison: Brittman: so what would cause an index to behave differently across 5.1 and 5.5 keeping in mind the mysql binaries were moved over to the new server and the index should be the same.