MySQL select dans outfile / tmp sans sortie

Question

Je ne peux pas obtenir le code suivant pour générer une sortie. L'utilisateur MySQL a " all " grant niveau, / tmp est accessible en écriture, la requête renvoie un ensemble de résultats.

mysql> SELECT field FROM test_table WHERE condition='test'
    -> INTO OUTFILE '/tmp/test.csv'
    -> FIELDS TERMINATED BY ','
    -> ENCLOSED BY '"'
    -> LINES TERMINATED BY '\n';
Query OK, 1 row affected (0.00 sec)

mysql>
[1]+  Stopped                 mysql
[root@web1 ~]# cat /tmp/test.csv
cat: /tmp/test.csv: No such file or directory

Dois-je voir une sortie différente de MySQL en cas d'échec?

Puis-je vérifier le résultat au-delà de "1 ligne affectée"?

Answer 1

Les fichiers générés par la clause outfile sont créés sur l'hôte du serveur mysql. Assurez-vous de regarder sur l’hôte du serveur mysql car il semble que vous êtes sur l’hôte client qui n’est probablement pas l’hôte du serveur mysql.

Voir http://dev.mysql.com/doc/refman /5.0/fr/select.html dans la section sur les fichiers externes pour la documentation à ce sujet.

Answer 2

Je suis tombé sur ce problème dans Fedora 17 qui était causé par systemd. Je pense que c'est bien de partager.

mysql> select * into outfile '/tmp/z1' from t1;
Query OK, 673 rows affected (0.01 sec)
mysql> select * into outfile '/tmp/z2' from t1;
Query OK, 673 rows affected (0.01 sec)
mysql> select * into outfile '/tmp/z1' from t1;
ERROR 1086 (HY000): File '/tmp/z1' already exists
mysql> Bye

# cat /tmp/z1
cat: /tmp/z1: No such file or directory
# ls -d systemd-*
/tmp/systemd-private-AQEueG
/tmp/systemd-private-AuCNDY
/tmp/systemd-private-TOMNxZ
/tmp/systemd-private-UacrpE
/tmp/systemd-private-yal7lQ
/tmp/systemd-private-ZlRJeN
# ls /tmp/systemd-private-TOMNxZ
z1  z2

Le coupable était dans /usr/lib/systemd/system/mysqld.service.

# Place temp files in a secure directory, not /tmp
PrivateTmp=true

Merci à ce blog , j'ai trouvé l'indice.

Answer 3

On dirait que vous rencontrez peut-être un problème d’autorisation de fichier. Assurez-vous que l’utilisateur: le groupe sous lequel mysqld est en cours d’exécution a l’autorisation adaqute d’écrire dans /tmp/test.csv

Il existe toute une gamme de types d'autorisations de démon de serveur / fichier permettant de résoudre le problème. Probablement basé sur UNIX, vous pourriez: chgrp mysqldGROUP / tmp

Mais cela semble si facile: votre serveur est configuré d’une certaine manière, vous vous y adaptez. Le processus mysqld ne devrait vraiment être capable de lire / écrire qu’à partir de quelques endroits.