wh33t — 2011-08-22T14:29:40-04:00 — #1
I've got a table in my database with 90,000 or so (it actually says ~82,944 right now, not sure what the ~ means?) and it gets updated every minute via a cron script. Sometimes during the update there will be inserts, sometimes deletes, sometimes updates, so it's really important to me that this table runs as smooth as possible. I realize most of this is probably going to be optimized in my php connection code, but I'd like to clear up some mysql questions as well.
Do I take a performance hit by having var chars and variable length fields in the table? Would it be better to just set them as chars of 255 in size? I have lots of hard drive space, so that's not a worry and I was thinking this might help.
Any tips in the right direction would certainly help.
guelphdad — 2011-08-22T14:49:34-04:00 — #2
You would take the hit the other way around. Specifying them as CHAR(255) they are always going to take up that length. Specifying them as VARCHAR(255) if a particular row is only 30 CHAR in length that is all it will take up.
by the way 90,000 rows is completely insignificant as far as table size goes. Think 90 million rows before you think table performance hits.
wh33t — 2011-08-22T14:57:11-04:00 — #3
I realize that 90k rows isn't a lot for MySQL, but this table get hits by cron scripts multiple times every minute, one script counts how many records are in a given category, another script updates a time field in it, another script adds into the table, another script checks every single record in the table (through out a 20ish hour period) to ensure the entry is still valid and that isn't even when a user wants to request data from the table.
So the table is basically under constant read/write access. It's sitting on an old AMD 2000xp+ Ubuntu Server with 1gb of memory and it runs quite slow for me on my own local network. I can't imagine how terrible it would run on shared hosting! So I'm trying to do all I can to avoid purchasing an expensive VPS when it goes live.
spacephoenix — 2011-08-22T15:03:22-04:00 — #4
What storage engine is the table using and are any fields in the table "Full Text" fields?
wh33t — 2011-08-22T15:06:13-04:00 — #5
I just swapped it to innoDB as some users from this forum suggested that would speed things up. I'm still not sure what a "Full Text" field is, but someone else said if I didn't know what they were, I probably wasn't using them.
Just to add in, I do have a field in my table structure that uses MEDIUMTEXT for storing of big strings but that's all I can relate "Full Text" to at the moment. :rofl:
r937 — 2011-08-22T16:41:57-04:00 — #6
that's called a tilde and in this context it means "approximately"
so your table has approximately 82,944 rows
wh33t — 2011-08-22T17:35:44-04:00 — #7
How can it only be approximate? Why wouldn't it just count it directly?
r937 — 2011-08-22T20:39:15-04:00 — #8
is the table innodb or myisam? the latter, since every update locks the table, always has an accurate count, but innodb doesn't keep a running total, you have to actually run a SELECT COUNT(*) query to get the exact count
spacephoenix — 2011-08-22T20:50:38-04:00 — #9
An alternative to running the extra query to get the count would be (if using php) count() (or an equivilant function in .net, asp, etc) on the array containing the result set
wh33t — 2011-08-22T22:44:09-04:00 — #10
It was Myisam, it's now innodb because everyone on the forums basically all informed me it would speed the site up. Oddly it appears to have made it much slower. >.< :nono:
spacephoenix — 2011-08-23T02:09:08-04:00 — #11
What indexes do you currently have on the table concerned?
wh33t — 2011-08-23T02:26:50-04:00 — #12
By indexes do you mean primary keys? Only one at the moment called article_id.
spacephoenix — 2011-08-23T02:36:45-04:00 — #13
The indexs can be found with
SHOW INDEXES FROM da_table_name
wh33t — 2011-08-23T03:16:27-04:00 — #14
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
listings 0 PRIMARY 1 listing_id A 159140 NULL NULL BTREE
listings 0 listing_url 1 listing_url A 159140 NULL NULL BTREE