Dyntex.net Support Centre: MySQL Reference Manual p.9

<< previous page -- table of contents -- next page >>

Chapter_1

Chapter_2

Chapter_3

Chapter_4

Chapter_5

Return to Table of Contents

Table of Contents
1. General Information
2. MySQL Installation
3. Tutorial Introduction
4. Database Administration
5. MySQL Optimisation
6. MySQL Language Reference
7. MySQL Table Types
8. MySQL APIs
9. Extending MySQL

Chapter 1: General Information 9 Linux-Intel 32 bit 2G, 4G or more, depends on Linux version Linux-Alpha 8T (?) Solaris 2.5.1 2G (possible 4G with patch) Solaris 2.6 4G (can be changed with ag) Solaris 2.7 Intel 4G Solaris 2.7 UltraSPARC 512G On Linux 2.2 you can get bigger tables than 2G by using the LFS patch for the ext2 lesystem. On Linux 2.4 patches also exist for ReiserFS to get support for big les. This means that the table size for MySQL databases is normally limited by the operating system. By default, MySQL tables have a maximum size of about 4G. You can check the maximum table size for a table with the SHOW TABLE STATUS command or with the myisamchk -dv table_name. See Section 4.5.6 [SHOW], page 251. If you need bigger tables than 4G (and your operating system supports this), you should set the AVG_ROW_LENGTH and MAX_ROWS parameter when you create your table. See Sec- tion 6.5.3 [CREATE TABLE], page 469. You can also set these later with ALTER TABLE. See Section 6.5.4 [ALTER TABLE], page 476. If your big table is going to be read-only, you could use myisampack to merge and compress many tables to one. myisampack usually compresses a table by at least 50%, so you can have, in eect, much bigger tables. See Section 4.7.4 [myisampack], page 279. You can go around the operating system le limit for MyISAM data les by using the RAID option. See Section 6.5.3 [CREATE TABLE], page 469. Another solution can be the included MERGE library, which allows you to handle a collection of identical tables as one. See Section 7.2 [MERGE tables], page 501. 1.2.5 Year 2000 Compliance The MySQL Server itself has no problems with Year 2000 (Y2K) compliance: MySQL Server uses Unix time functions and has no problems with dates until 2069; all 2-digit years are regarded to be in the range 1970 to 2069, which means that if you store 01 in a year column, MySQL Server treats it as 2001. All MySQL date functions are stored in one le, `sql/time.cc', and are coded very carefully to be year 2000-safe. In MySQL Version 3.22 and later, the new YEAR column type can store years 0 and 1901 to 2155 in 1 byte and display them using 2 or 4 digits. You may run into problems with applications that use MySQL Server in a way that is not Y2K-safe. For example, many old applications store or manipulate years using 2-digit values (which are ambiguous) rather than 4-digit values. This problem may be compounded by applications that use values such as 00 or 99 as \missing" value indicators. Unfortunately, these problems may be dicult to x because dierent applications may be written by dierent programmers, each of whom may use a dierent set of conventions and date-handling functions.

MySQL Reference Manual

Our Partners

SpiritHost - web hosting for spiritual and education sites
SpiritHit.com - Religious and Spiritual Portal

Return to Table of Contents	Back to top

Web Hosting: Manuals & FAQ's

1. Unix-Based Web Hosting
2. Unix Dedicated Servers
3. Windows Dedicated Servers
4. CuteFTP User’s Guide
5. CuteHTML User’s Guide
6. WS_FTP Pro User's Guide
7. Miva Order User's Guide
8. Miva Merchant User's Guide