Por dios Skeletron un VARCHAR de longitud 300 como Primary Key    intenta no hacer esto. Ten siempre pendiente recordar que los campos que vas a definir como PK que sean de longitud constantes o fijas (char, int, tinyint, smallint, etc) Y no de longitud variable (varchar) los datos de longitus variable suelen desfragmentarse mucho... no lo uses como indices.


CRC64 hasta lo que yo se, No existe en MySQL como funcion. La funcion Matematica CRC32 retorna valores unicos que no sobrepasan las 11 cifras por mas larga que sea la entrada que estas convirtiendo con CRC32 Por este lado Skeletrun confia.

Yo particularmente no recomendaria ni MD5 ni SHA1 para indice, la razon ademas de que retorna un tamano en bits mayor (algo que quiere evitarse Skeletrum) no son datos numericos sino alfanumericos... por lo cual sabes que en lenguaje de computador es mucho mas rapido la lectura de datos numericos que alfanumericos ya que los alfanumericos deben traducirse primero a numericos (aunque sea en fraciones de milisegundos pero segun lo hace) para poder interpretarlos. Entonces considerando lo anterior, CRC32 es mejor porque ahorra bityes de espacio, son caracteres siempre numericos y no sobrepasan las 11 cifras. (Hasta la fecha No he visto colisiones usando esta funcion la CRC32 en millones de datos, para mi hay una alta posibilidad que funcione acorde a lo que he visto... pero, no podria descartar que a lo mejor colisione alguna vez pero particularmente en millones de datos yo no lo he visto aun).

Que conste que la idea de insertar campos indices con la funcion CRC32 la obtuve de un ejemplo del libro 'High MySQL Optimization' escrito por la gente de Percona, esa misma gente que mencionas Vertex en los links que refieres... esa sugerencia la obtuve de ellos y hasta la fecha a mis amistades developers webs le ha servido enormemente. 

Lol constantemente me pasa eso... aunque visualmente sigo navegando dentro del foro supuestamente logeada hasta veo mi perfil y puedo editar cosas de mi perfil y todo... pero cuando voy a postear algo me dice 'Sesion invalida este usuario no existe' o similar, asi que cierro el navegador vuelvo y lo abro y todo bien.

Yo no te he bloqueado..... no suelo bloquear a nadie por msn.

Si solo debes obtener la data de un unico valor en tu tabla .... haz probado:

SELECT * FROM TABLA WHERE CAMPO = VALOR

 

O la data esta dividida entre varias tablas y requieras hacer un JOIN? Que el proceso seria similar o igual:

SELECT  CAMPO1, CAMPO2 FROM TABLA1 INNER JOIN TABLA2 WHERE CAMPO1 = VALOR AND CAMPO2 = CAMPO1

Hola.

Conozco a los chicos de mysqlperformanceblog  son los mismos chicos de Percona    son un grupo de consultores profesionales en MySQL. De hecho ellos mismos escribieron el libro 'MySQL Optimization' el cual he leido como 3 veces ya    pero estoy registrada en su foro y lo visito mucho para aprender cosas que aun no sepa. Eso de crear 1 tabla extra con indices y que busque bajo una condicion cuando usar la tabla indices y cuando no... es un proceso que no sabria yo si fuese muy conveniente. Ya que no solo es crear un Analizador que te haga esto, sino tambien darle mas tarea a la base de datos al utilizar varios JOINS de tablas bajo ciertas condiciones... puede ahorrarse un reducido tiempo en hacerlo todo directo... pero siempre hay opciones que considerar.


Ten algo pendiente si tus tablas son Myisam y defines como indices varios campos que eran data en la tabla.. estos pasan al archivo .MYI y ya no siguen en .MYD  ademas de la grandisima ventaja que los indices en Myisam se guardan en un buffer cache del motor MySQL, sin embargo la Data se guarda en la cache ram del sistema operativo    por ende la busquedad y lectura de indices es mas rapida porke esta en el buffer de MySQL y no en el buffer que maneja el sistema operativo, por ende es normal que reduzca en tamano el archivo MYD.

Tus indices son hash indices??? son datos constantes de longitud constante cierto?


Implica que la longitud de ese campo soporta 12 numeros decimales sin punto.. por ejemplo si defines un campo asi:

DECIMAL(5,3)

Implica que dicho campo soportara 5 numeros nada mas, pero de esos 5 numeros debes colocar 1 punto (de decimal) antes de las 3 ultimas cifras, me explico si quieres insertar el valor:

30000
40000

No puedes insertarlo asi a pelo en la tabla, porque te dara error, debes insertarlo asi:

30.000
40.000

De igual manera si tu campo fuese DECIMAL(6,2)  indica que soporta una cifra de 6 numeros pero colocandole un puntito antes de los 2 ultimos:

3000.00
4000.00

Se entiende??? 

PD: Por cierto que fue lo que aplicaste de lo que yo te dije?? Usaste Myisampack???

Yo nunca he utilizado INFORMIX pero, despues de ver que internamente varios motores tienen un funcionamiento similar.

Puedes intentar realizar el COUNT a los indices (campos indices) de cada tabla dentro del JOIN????

Por ejemplo:

mysql> SELECT COUNT(*) FROM ejemplo;
+----------+                        
| COUNT(*) |                        
+----------+                        
|    15000 |                        
+----------+                        
1 ROW IN SET (0.00 sec)             
 
mysql> SELECT COUNT(*) FROM copia;
+----------+                      
| COUNT(*) |                      
+----------+                      
|    20000 |                      
+----------+                      
1 ROW IN SET (0.00 sec)           
 
mysql> SELECT COUNT(numero), COUNT(numerito) FROM ejemplo INNER JOIN copia ON ejemplo.numero = copia.numerito;
+---------------+-----------------+
| COUNT(numero) | COUNT(numerito) |
+---------------+-----------------+
|         15000 |           15000 |
+---------------+-----------------+
1 ROW IN SET (0.34 sec)
 
 

Nada mal 0.34 segundos    ahora checa sino hago el COUNT a los indices:

mysql> SELECT COUNT(nombres), COUNT(apellidos) FROM ejemplo INNER JOIN copia ON copia.codigo = ejemplo.codigo ; +----------------+------------------+                                                                                                              
| COUNT(nombres) | COUNT(apellidos) |                                                                                                              
+----------------+------------------+                                                                                                              
|          15000 |            15000 |                                                                                                              
+----------------+------------------+                                                                                                              
1 ROW IN SET (4 MIN 16.36 sec)                                                                                                                     
 
 

4 minutos y 17 segundos 

Intentalo el desempeno debe ser similar.

Tu sabes que cualquier cosa hasta donde mi capacidad pueda ayudar.... ayudo 

si estas seguro que te conviene mejor 1 usuario en Mysql por cada usuario perfecto. No lo he probado aun, pero puedo casi asegurar acorde a la forma como Mysql trabaja, que hay una manera de impedir que remotamente por una terminal o similar un usuario se conecte (aun conociendo su contrasena y usuario)    y que asi el usuario solo pueda conectarse a traves de la web que tu le otorgaras... si te interesa como hacerlo porque te preocupe esta parte me avisas y te digo, asi lo pruebas y vemos si funciona y te liberas de pensar que un usuario curioso accese por un cliente mysql desde su PC al servidor Mysql a ver cosas que no debe ver.

                

Bueno, que es mejor un usuario dentro de Mysql por cada usuario, o una tabla que maneje los usuarios....  dejame ver.

Si eligieras crear 1 usuario dentro de Mysql por cada usuario :

1 - No necesitarias crear ni utilizar una tabla 'Usuarios'
2 - La autentificacion seria directamente hacia el motor Mysql

Ahora que tiene de negativo? que los usuarios como conocen su contrasena y usuario, pueden perfectamente desde un cliente (terminal) mysql loguearse de forma remota o dentro de la red al servidor mysql por linea de comando, y ver a que tablas este tiene permisos y cuales permisos. (pero obviamente esto se puede controlar con permisos). Pero fuera de ahi hasta ahora no veo un inconveniente muy grave, y si haces esto asi, ahi si podras usar libremente la funcion CURRENT_USER() y funcionara 

Si eligieras crear 1 campo extra en la tabla a modificar, ahi a lo mejor tendrias mas trabajo que realizar por codigo y eso, pero el usuario no tendria o no conoceria la forma de acceder por terminal a mysql remoto.

Pero obviamente estos usuarios deberian conocer del tema y como funciona Mysql, pero no hay nada que no puedas controlar repito dependiendo los permisos que otorgues a cada usuario. Pero que conviene? de esta parte podrias elegir cualquiera de las dos, sabiendo tu la capacidad de esos usuarios y hasta donde pueden llegar.

oye estan super tiernos    me encantan  quiero llevarme uno de estos a casa conmigo (no me malinterpreten es normal que me agraden como es normal que les agraden a cualquier chica  ) Pero observando que el 97% de usuarios del foro es masculino, encontrarian un set de este tipo muy gay... sin ofender a los gays.

Pero entre las opciones previamente mostradas sobre la encuesta de cuales emoticones elegir para el foro... esta fuerte la decision si ... cual de todos mas feos    sin ofender a los disenadores terceros que crearon dichos emoticones.

Hay muchos emoticones para SMF por ahi, incluso creo que uno hasta por cada estacion del año ... por si estan muy naturalisticos aca 

Unos emoticonos de Bart Simpson no querran...