primary key performance
I have a pretty standard database schema here with the primary key prod_id being my most often used join column in select queries. Categories, rankings .. just about anything having to do with products uses prod_id in a join, and user access on these queries is pretty heavy. I wonder whether the performance of a select join depends on the length of that column. Given that it is a primary key I have indexing on it, and all other rules apply, but is there a difference in performance (CPU) between: - 10 products in both cases. One time the column is a MediumInt, the other time a BigInt. I know there is a difference in disk space usage, but is there also one in performance at all ? - 10 products in both cases. One table has its prod_id span from exactly 1 to 10, the other one uses any random values between 1 and ... ahh lets say 884570294. Any performance issue ? Curious about what you guys have to say, anyway ... Dan. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Do I specify a primary key to be primary, unique and index ?
I learned that there are three types of indexes (PRIMARY, UNIQUE, and INDEX). Now assuming I create a performance-critical PRIMARY key, will I better have to specify UNIQUE and INDEX for this column also !? It should be obvious that a primary key is unique anyway, and an index as well, shouldnt it !? Please note, I am not after saving disk space here, performance is all I am after, and such a three-fold indexing exercise just seems redundant to me in the best case scenario, or harmful even, am I right there !? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
