My terribly archaic Database

[cavedude]

Smaller tables that aren't used much generally benefit more from MyISAM over InnoDB. However, it wouldn't hurt to convert everything over. The only table I would highly recommend you leave MyISAM is character_backup. I'm not sure about you, but TGC's table is huge. Converting to InnoDB would waste so much space it's silly, and for that table you wouldn't really see much peformance boost at all, if any.

[Kobaz]

Tables that aren't UPDATED often and aren't huge tend to be faster with myisam. innodb has row-level locks, whilst myisam only has table-level locks. None of the tables in eqemu are really huge, so it's the locking that's going to make the biggest difference on tables that have frequent updates. Innodb also clusters data about the primary key, so SELECTs are quicker when the WHERE clause uses that key.

So I would hesitate to convert everything to innodb unless you have extremely fast drives, although any table that might have concurrent writes to different rows could be quicker with innodb.

I've noticed a marked slowdown on build 488 vs the 450's, with higher loads on mysql. I suspect there was a query introduced that would benefit from better indexing.

[trevius]

Originally Posted by cavedude

Smaller tables that aren't used much generally benefit more from MyISAM over InnoDB. However, it wouldn't hurt to convert everything over. The only table I would highly recommend you leave MyISAM is character_backup. I'm not sure about you, but TGC's table is huge. Converting to InnoDB would waste so much space it's silly, and for that table you wouldn't really see much peformance boost at all, if any.

Cavedude, I have been thinking about starting a discussion about the player profile blobs. This thread may not be the place for it, but since table size and performance is being mentioned, it makes me think about it. Currently, our profile blob is built from an old player profile packet that is no longer used. Essentially, this means that the structure of it doesn't matter to us at all anymore, we just use it to pull data from. The issue is that over half of the player profile blob is from unknowns in the PP struct. This means that half of the character_ and character_backup table space is being wasted for no reason. If we would remove the unknowns from the profile struct and only store stuff that is known, I think it would cut database backup size nearly in half of what it currently is. It may also help performance as well.

The actual change itself should be as simple as editing the common/eq_packet_structs.h player profile struct. The only problem is that will make any profile created before the change unusable unless it was converted. That is the worst part about making a change like this, but it might be worth considering if we had a way to convert all of the old profiles all at once. It may not be worth the risk, but if we had a good safe way to do the conversions (maybe in game command?), this could potentially have a pretty big impact on performance and backup file sizes.

Something to maybe consider or discuss further. If the idea is worth considering, we can start a discussion on it in the development forum to get input on the best way to handle it.

[cavedude]

Trev, that's a really good thought but the problem is what if down the road we identify those unknowns? Then, we'd have to go through the conversion process all over again. I think the fewer times we convert, the safer and better off all of us will be.

[trevius]

I already explained a bit more about it here:
http://www.eqemulator.net/forums/sho...96&postcount=3

But ultimately, it probably isn't worth the extra effort I guess. I am probably going to have to make changes to that structure anyway soon for SoF to reach full functionality. Luckily, none of the changes I would be making should cause any impact at all on previously saved profiles. I won't be adjusting the size of the structure or adjusting where fields currently are. I would just be adding more stuff in where there are some unknowns currently. If I do have to change anything, I will make sure to run it by you and KLS first, since the risk of issues is high when dealing with the PP. As long as size of the total struct doesn't change and no current field positions change, it shouldn't cause any issues.

Sorry for getting off-topic, but the reason for mentioning it was to possibly help optimize everyone's database a bit.

[KingMort]

Should I be using the launcher???

What Priority should the zones be set at, and world..

King

[John Adams]

I used to debate the pros/cons of both MyISAM and Blobs. Hate them both, because I am a constraint freak (ask LE, I may have convinced our team to use InnoDB for FK constraints ). Saves a lot of processing time cascading updates/deletes within MySQL than having an executable run 15 update/delete queries, but again, just my opinion based on my own analysis and research.

I hate the blobs simply because they are... blobs. Unreadable, unless you convert them... and, well, blobby. It shouldn't matter how the data is stored in the DB, as long as the server/client talk the same blobby language.

And you're right, probably not the place to debate it. But I am still thinking of KM's issue, not really sure why he'd be seeing such poor performance unless the hardware is just utter crap.

[Shendare]

Adding indexes to table columns that are often sorted or filtered by can yield a huge performance boost in tables that are read from often but added to rarely (adding a record takes longer with a large table containing many indexes to update).